TITLE OF THE INVENTION 

BUS MANAGER AND CONTROL APPARATUS FOR MULTIFUNCTION DEVICE 

HAVING SAID BUS MANAGER 

5 

BACKGROUND OF THE INVENTION 

This invention relates to a control apparatus for a 
multifunction device for efficient control of an image input 
10 unit such as a scanner and an image output unit such as a 
printer . 

Copiers and facsimile machines which combine an image 
input unit such as a scanner and an image output unit such 
as a printer, as well as computer systems equipped with these 

15 as separate units, are now in practical use. Such systems 
require the efficient processing of enormous amounts of data 
in order to handle image data. 

Such systems rely upon DMA transfer using a plurality 
of bus masters in order to transfer data. In a case where 

20 a plurality of bus masters execute processing in successive 
fashion, a series of processing operations is conceivable 
in which data in memory is first subjected to processing A 
(bus master 1) and then to processing B (bus master 2) , after 
which the processed data is sent to a bus master 4. 

25 If a DMA (Direct Memory Access) function in which each 

bus master reads the data from the memory and then writes 
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the processed data back to the memory is available when 
performing such processing, usually the pertinent software 
sets DMA in such a manner that bus master 1 executes 
processing A. After master 1 has completed all processing, 
5 the software interrupts the processor and sets DMA in such 
a manner that processing will be terminated* After this 
processing is completed, the software sets DMA in such a 
manner that bus master 4 reads data out of the memory. Thus, 
in order to perform this series of processing operations, 
10 it is necessary to execute processing by software in such 
a manner that after the completion of one processing 
operation is verified, the next processing operation is 
started. 

15 SUMMARY OF THE INVENTION 

Thus, it is necessary for software to intervene whenever 
each processing operation is executed. In addition, it is 
necessary for the processed data to be written back to memory 

20 each and every time processing is executed. A first problem, 
therefore, is too much needless processing. 

Further, owing to handling of a large quantity of data, 
a bottleneck develops in terms of bus transfer ability owing 
to use of a single bus. In order to eliminate this problem, 

25 a system using dual buses to improve transfer capability has 
been developed. However, even if a system has a plurality 
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of buses, the bus arrangement lacks flexibility 'and 
sufficient transfer capability is not obtained in a case 
where a large quantity of data is transferred. This is a 
second problem with the prior art. 
5 The usual practice is to use a single bus. In a case 

where a plurality of bus masters attempt to write data to 
the same memory address, the writing of data to memory in 
the order in which bus use privilege is acquired can be 
assured. However, in a system configuration in which bus 

10 arbitration of these buses and the connection of any one of 
these buses to the memory are carried out independently, 
there is a possibility that a plurality of bus masters 
connected to a plurality of buses will write to the same data 
space simultaneously, and there is a possibility that the 

15 write sequence will not be the sequence in which bus use 
privilege is obtained by bus arbitration. This is a third 
problem of the prior art. 

Furthermore, a cache memory is used in the prior art 
to process data efficiently. Conventional cache control, 

20 however, is such that the cache is turned on and off based 
upon address information of the memory that is the 
destination of the data transfer. When a large quantity of 
data is transferred to a memory space for cache storage, 
therefore, a large quantity of data is cached and the memory 

25 space is rewritten entirely by new data. If another device 
accesses the memory, there is a good possibility of a cache 
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miss. Though increasing cache storage capacity may appear 
to be a solution, this leads to a major increase in 
manufacturing cost. In particular, when printing or the like 
is carried out, a large quantity of data that has been read 
5 out is delivered to the printer engine and, even though the 
data has been cached, it is not used twice. Caching data 
indiscriminately in this manner rather lowers the cache hit 
rate. Thus, a fourth problem is that cache memory cannot 
be used efficiently. 

10 In a system employing a plurality of buses, it is 

required that a bus master that is capable of using the 
plurality of buses decide which bus to use. Conventionally, 
once the destination to be accessed has been determined, the 
bus is decided accordingly. However, a fifth problem is that 

15 since the bus used is fixed in dependence upon the 

destination, it is not possible to make effective use of buses 
that takes into account the transfer speed and ratio of use 
of each bus. 

Furthermore, a sixth problem is that when such a system 
20 is integrated on a single semiconductor chip, a large 

quantity of heat is evolved and may damage the package and 
chip. 

Accordingly, in view of the first problem set forth 
above, a first object of the present invention is to provide 
25 a bus manager and a control apparatus for a multifunction 
device having the bus manager in which overall processing 
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speed is raised without requiring the intervention of 
software for each and every processing operation. 

In view of the second problem set forth above, a second 
object of the invention is to provide a bus manager and a 
5 control apparatus for a multifunction device having the bus 
manager in which the bus arrangement is provided with 
flexibility and data transfer can be carried out upon 
selecting the optimum bus. 

In view of the third problem set forth above, a third 
10 object of the present invention is to provide a bus manager 
and a control apparatus for a multifunction device having 
the bus manager in which it is possible to access a memory, 
from bus masters connected to respective ones of a plurality 
of buses, in the order in which the privilege to use the buses 
15 was obtained. 

In view of the fourth problem set forth above, a fourth 
object of the present invention is to provide a bus manager 
and a control apparatus for a multifunction device having 
the bus manager in which the efficiency with which a cache 
20 is used is improved. 

In view of the fifth problem set forth above, a fifth 
object of the present invention is to provide a bus manager 
and a control apparatus for a multifunction device having 
the bus manager in which the bus used by each bus master is 
25 decided dynamically to improve bus efficiency. 

In view of the sixth problem set forth above, a sixth 
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object of the present invention is to provide a bus manager 
and a control apparatus for a multifunction device having 
the bus manager in which the operating status of circuitry- 
is monitored to suppress power consumption and, hence, the 
5 evolution of too much heat. 

According to the present invention, the foregoing 
objects are attained by providing a bus manager comprising 
at least one bus, a plurality of bus masters connected to 
the bus, means for storing conditions for starting and 

10 conditions for ending granting of bus use privilege to each 
of the plurality of bus masters, and bus arbitration means 
for granting the plurality of bus masters the bus use 
privilege or depriving the plurality of bus masters of the 
bus use privilege in accordance with the conditions if there 

15 are bus use requests from the plurality of bus masters. 
In another aspect of the present invention, the 
foregoing objects are attained by providing a bus manager 
comprising at least four buses, bus masters connected to the 
buses, and changeover means for changing over a connection 

20 among the buses in conformity with bus requests from bus 
masters connected to respective ones of the buses. 

In another aspect of the present invention, the 
foregoing objects are attained by providing a bus manager 
comprising at least two buses each having a bus master, a 

25 memory accessed via the buses, arbitration means connected 
to respective ones of the buses for arbitrating bus requests 
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from the bus masters of the corresponding buses and 1 granting 
a bus use privilege to any of the bus masters, and bus 
synchronizing means operable, in a case where a plurality 
of bus masters that have been granted bus use privilege with 
5 respect to the respective buses perform a write operation 
with respect to the same destination, for so notifying the 
arbitration means so that the arbitration means will stop 
the granting of the bus use privilege to the bus masters with 
the exception of a bus master that issued the bus request 
10 first. 

In another aspect of the present invention, the 
foregoing objects are attained by providing a bus manager 
comprising at least two buses each having bus arbitration 
means, bus masters connected to the buses, and decision means 

15 for judging status of each of the buses and information 
relating to bus requests issued by the bus masters, and 
deciding which of the buses should be used* 

According to another aspect of the invention, the 
present invention provides a memory manager comprising a 

20 memory for supporting a burst mode in which a data transfer 
to successive locations is carried out, and memory control 
means having a cache memory preceding the memory for 
temporarily storing data exchanged with the memory, wherein 
the memory control means controls the cache memory in such 

25 a manner that data is transferred to the memory directly 
without the intermediary of the cache memory if transfer of 
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the data to the memory is performed in the burst mode, and 
such that data is first written to the cache memory if 
transfer of the data to the memory is performed in a single 
mode* 

5 In another aspect of the present invention, a memory 

manager comprises a memory for supporting a burst mode in 
which a data transfer to successive locations is carried out, 
memory control means having a cache memory preceding the 
memory for temporarily storing data exchanged with the 

10 memory, and a plurality of bus masters which access the 
memory, wherein the memory control means performs control 
in such a manner that data is transferred to the memory 
directly without the intermediary of the cache memory, or 
is transferred to the memory upon first writing the data to 

15 the cache memory, in dependence upon the bus master that is 
to transfer the data to the memory. 

According to another aspect of the present invention, 
the present invention provides a power manager for 
controlling power consumption of an electric circuit which 

20 includes a plurality of circuit blocks controlled by a 
controller, comprising status monitoring means for 
monitoring operating status of each circuit block, adding 
means for summing power consumed by each circuit block in 
the operating state, and notification means for comparing 

25 summed power with a predetermined threshold value and, if 
the summed power exceeds the threshold value, so notifying 
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the controller* 

Other features and advantages of the present invention 
will be apparent from the following description taken in 
conjunction with the accompanying drawings, in which like 
5 reference characters designate the same or similar parts 
throughout the figures thereof. 



BRIEF DESCRIPTION OF THE DRAWINGS 



10 The accompanying drawings, which are incorporated in 

and constitute a part of the specification, illustrate 
embodiments of the invention and, together with the 
description, serve to explain the principles of the 
invention . 

15 Fig. 1 is a diagram showing the configuration of an 

apparatus or system using a DoEngine; 

Fig. 2 is a diagram showing the configuration of an 
apparatus or system using a DoEngine; 

Figs. 3A-3C are diagrams showing the examples of 
20 apparatuses using a DoEngine; 

Fig. 4 is a block diagram of a DoEngine; 
Fig. 5 is a diagram showing three states of a cache 
memory controller; 

Fig. 6 is a block diagram showing an interrupt 
25 controller; 

Fig. 7 is a block diagram showing a memory controller; 
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Fig. 8 is a detailed block diagram the focus- of which 
is a cache controller; 

Fig, 9 is a flowchart showing operation of a cache when 
memory read/write transfer has been requested from an MC bus ; 
5 Fig. 10 is a flowchart showing operation of a cache when 

memory read/write transfer has been requested from an MC bus ; 

Fig. 11 is a diagram showing the construction of a 
ROM/ RAM controller; 

Fig. 12 is a timing chart showing the timing of burst 
10 readout from a CPU; 

Fig. 13 is a timing chart showing the timing of burst 
write from a CPU; 

Fig. 14 is a timing chart showing the timing of burst 
readout from a G bus device; 
15 Fig. 15 is a timing chart showing the timing of burst 

write from a G bus device; 

Fig. 16 is a timing chart showing the timing of single 
readout in a case where a hit has occurred in a memory front 
cache ; 

20 Fig. 17 is a timing chart showing the timing of single 

readout in a case where a hit has not occurred in a memory 
front cache; 

Fig. 18 is a timing chart showing the timing of single 
write in a case where a hit has occurred in a memory front 
25 cache; 

Fig. 19 is a timing chart showing the timing of single 
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write in a case where a hit has not occurred in a memory front 
cache ; 

Fig. 20 is a block diagram of a system bus bridge (SBB) ; 
Fig. 21 is a block diagram of an 10 bus interface; 
5 Fig. 22 is a block diagram of a G bus interface; 

Fig. 23A shows a virtual memory map; 
Fig. 23B shows a physical memory map; 
Fig. 23C is a memory map of G bus address space; 
Fig. 23D is a memory map of 10 bus address space; 
10 Fig. 24A is a map showing 512 MB of the shaded portion 

in Fig. 23A, which includes a register, etc.; 

Fig. 24B is a map showing 512 MB of the shaded portion 
in Fig. 23B, which includes a register, etc.; 

Fig. 24C is a map showing 512 MB of the shaded portion 
15 in Fig. 23C, which includes a register, etc.; 

Fig. 24D is a map showing 512 MB of the shaded portion 
in Fig. 23D, which includes a register, etc.; 

Fig. 25 is a block diagram of an address switch 2003; 
Fig. 26 is a block diagram of a data switch 2004; 
20 Fig. 27 is a timing chart of write/read cycles from a 

G bus; 

Fig. 28 is a timing chart showing the burst stop cycle 
of a G bus; 

Fig. 29 is a timing chart showing the transaction stop 
25 cycle of a G bus; 

Fig. 30 is a timing chart showing the transaction stop 
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cycle of a G bus; 

Fig. 31 is a timing chart showing the transaction stop 
cycle of a G bus; 

Fig, 32 is a timing chart showing the transaction stop 
5 cycle of a G bus; 

Fig. 33 is a block diagram showing a PCI bus interface; 

Fig. 34 is a block diagram showing aG bus arbiter (GBA) ; 

Fig. 35 is a block diagram relating to DMA by bus masters 
on a G bus, with the focus being on a G bus in a DoEngine; 
10 Fig. 36 is a diagram showing an example of a fair 

arbitration mode (fair mode) in a case where the number of 
times a bus is used in succession is set to one in regard 
to all bus masters 1-4; 

Fig. 37 is a diagram showing an example of a fair 
15 arbitration mode in a case where the number of times a bus 
is used in succession is set to two in regard to bus master 
1 and to one in regard to other bus masters; 

Fig. 38 is a diagram showing an example of a high- 
priority arbitration mode in a case where the number of times 
20 a bus is used in succession is one each, with bus master 1 
being set as a high-priority bus; 

Fig. 39 is a diagram showing an example in which, despite 
the fact that a bus request from bus master 4 has been allowed, 
the request is canceled by a bus request from bus master 1; 
25 Fig. 40 is a block diagram of an 10 bus arbiter; 

Fig. 41 is a block diagram of a synchronization unit; 
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Fig. 42 is a diagram of one comparator in the 
synchronization unit; 

Fig. 43 is a block diagram of a scanner /printer 
controller; 

5 Fig. 44 is a block diagram of a scanner /video 

synchronization control unit; 

Fig, 45 is a block diagram of a printer /video 
synchronization control unit; 

Fig, 46 is a block diagram of a scanner FIFO controller; 
10 Fig. 47 is a block diagram of a printer FIFO controller; 

Fig. 48 is a block diagram of a data transfer control 

unit ; 

Fig. 49 is a block diagram of a chain controller; 
Fig. 50 is a block diagram of a G bus/10 bus interface 

15 unit; 

Fig. 51 is a block of a bus selector unit; 
Fig. 52 is a block diagram of an 10 bus controller; 
Fig. 53 is a block diagram of a G bus controller; 
Fig. 54 is a block diagram of a power management unit; 
20 Fig. 55 is a block diagram of a bus agent; 

Fig. 56 is a flowchart showing another example of cache 
operation in a case where memory read/write transfer has been 
requested from an MC bus; 

Fig. 57 is a flowchart showing another example of cache 
25 operation in a case where memory read/write transfer has been 
requested from an MC bus; 
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Fig. 58 is a flowchart showing another example of cache 
operation in a case where memory read/write transfer has been 
requested from an MC bus; and 

Fig. 59 is a flowchart showing another example of cache 
5 operation in a case where memory read/write transfer has been 
requested from an MC bus. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

10 A so-called "DoEngine" will be described as an 

embodiment of the present invention. The DoEngine is a 
single-chip scanning and printing engine having an internal 
processor core, a processor peripherals controller, a memory 
controller, a scanner /printer controller and a PCI 

15 interface. 

1. Overview of DoEngine 

A DoEngine is a single-chip scanning and printing engine 
internally incorporating a processor core compatible with 
the R4000 processor manufactured by MIPS Technologies, Inc. , 
20 a processor peripherals controller, a memory controller, a 
scanner/printer controller and a PCI interface . The DoEngine 
employs high-speed parallel operation and building-block 
techniques . 

It is possible to internally incorporate a 3 2 -KB cache 
25 memory having a maximum of 16 KB of memory for each of 
transactions and data, an FPU (floating-point operation 
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unit) , an MMU (memory management unit) and a user definable 
coprocessor in the processor shell (the generic term for the 
processor peripherals circuitry inclusive of a coprocessor) . 
Since the DoEngine has a PCI bus interface, it is capable 
5 of being used together with a computer system having a PCI 
bus slot. In addition to being usable in a PCI satellite 
configuration, the DoEngine is capable of being issued in 
a PCI bus configuration in the form of a PCI host bus bridge. 
By being combined with an inexpensive PCI peripheral device, 

10 the DoEngine can also be used as the main engine of a 

multifunction peripheral. Furthermore, it is also possible 
to combine the DoEngine with a rendering engine or 
compression/expansion engine having a PCI bus interface. 
The DoEngine has two independent buses within its chip, 

15 namely an 10 bus for connecting a general-purpose 10 core 
and a graphics bus {G bus) optimized for transfer of image 
data . High-speed data transfer with a high degree of parallel 
operation essential for simultaneous operation in a 
multifunction switch is realized by connecting a memory/ a 

20 processor and the buses thereof via a crossbar switch. 

In order to support a synchronous DRAM (SDRAM) having 
maximum cost performance and minimize a decline in random 
accessing performance in small data units which cannot enjoy 
the merits of the burst access high-speed data transfer of 

25 a SDRAM in regard to the accessing of a continuous data 
string, which is typified by image data, an 8-KB 2-way set 



- 15 - 



associative memory front cache is provided within the memory 
controller, A memory front cache makes it possible to realize 
higher performance by cache memory without a complicated 
construction even in a system configuration employing a 
5 crossbar switch in which bus snooping for all memory write 
operations is difficult. The DoEngine has a data interface 
(video interface) , which is capable of real-time data 
transfer (device control), for interfacing a printer and 
scanner. High-quality, high-speed copying can be achieved 

10 even in an arrangement in which the scanner and printer are 
discrete devices by supporting synchronization between 
devices and executing image processing by hardware. 

The DoEngine has a core that operates at 3 . 3 V and an 
10 unit that operates at 5 V. 

15 Figs. 1, 2, and3A-3C show examples of the configuration 

of an apparatus or system using the DoEngine. Fig. 1 shows 
a distributed arrangement in which a local board 101 having 
a DoEngine is connected to a personal computer 102 via a PCI 
interface possessed by the DoEngine. Besides having the 

20 DoEngine, the local board 101 is provided with a memory, which 
is connected to the DoEngine via a memory bus, described 
later, and color processing circuit (chip) . A high-speed 
scanner 103 and a color/monochromatic printer 104 are 
connected to the personal computer 102 via the local board 

25 101. By virtue of this arrangement, image information that 
has entered from the high-speed scanner 103 can be processed 



- 16 - 



by the local board 101 and output from the printer 104 under 
the control of the personal computer. 

Figs. 2 and 3A-3C show examples in which a scanner 203 
and printer 202 are incorporated in the same device. Fig. 
5 2 shows a configuration resembling an ordinary copier, Fig. 
3A illustrates the arrangement of a facsimile apparatus or 
the like, and Fig. 3B shows a computer for controlling the 
arrangement of Fig. 3A. 

Figs. 1 and 2 show examples of use in a slave mode, in 

10 which the DoEngine is controlled by an external CPU connected 
via the PCI interface. Figs. 3A-3C show examples of use in 
a master mode, in which the CPU of the DoEngine is the nucleus 
and controls the device connected via the PCI interface. 
Table 1 illustrates the specifications of the DoEngine. 

15 The DoEngine is equipped with a PCI, memory bus, video, 
general-purpose input /output, IEEE 1284, RS232C, 
lOObaseT/lObaseT, LCD panel and keys as external interfaces. 
As for the internal blocks, the DoEngine is equipped with 
a primary cache, a memory controller with cache, a copy 

20 engine, an 10 bus arbiter and a graphic bus arbiter, etc., 
in addition to the CPU core. A DMA controller has five 
channels and arbitration is carried out in accordance with 
a priority first-come first-served scheme along with the 
graphics bus and 10 bus. 

25 
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TABLE 1 



ITEM 


SUMMARY 


SPECIFICATIONS 


CHIP 


OPERATION FREQUENCY 
PACKAGE 

EXTERNAL INTERFACE 


INTERNAL: 100 MHz; EXTERNAL 
BUS & MEMORY BUS: 100 MHz 
313-PIN BGA 
PCI 

MEMORY BUS 
VIDEO 

GENERAL- PURPOSE I/O 

IEEE1284 

RS232C 

(USB) 

LAN 100/10baseT 
LCP PANEL & KEYS 




INTERNAL BLOCKS 


CPU CORE 
PRIMARY CACHE 
MMU 
ICU 

SYSTEM BUS BRIDGE 
CONTROLLER W. CACHE 
COPY ENGINE 
PLL 

POWER CONTROL UNIT 
IO BUS ARBITER 
GRAPHICS BUS ARBITER 


DMA CONTROLLER 
MEMORY & BUS CONTROL 

GRAPHICS BUS 
PCI BUS 
IO BUS 


NUMBER OF CHANNELS 

MAX. TRANSFER SPEED (PEAK) 

TRANSFER-CAPABLE PATH 

SUPPORT MEMORY 
DATA WIDTH 

MAXIMUM MEMORY CAPACITY 
MAXIMUM MEMORY BUS TRANSFER 
SPEED 

ARBITRATION METHOD 

MAXIMUM BUS TRANSFER SPEED 

BUS WIDTH 

PCI BUS FORMAT 

TRANSFER SPEED WHEN MASTER 

TRANSFER SPEED WHEN SLAVE 

ARBITRATION METHOD 

MAXIMUM BUS TRANSFER SPEED 
BUS WIDTH 


FIVE CHANNELS 

200 MB/s @ 50 MHz 

INTERNAL OUTPUT BLOCK ^ 

LOCAL MEMORY 

SDRAM 

64 BITS 

1 GB 

682 MB/s 

PRIORITY FIRST-COME FIRST- 
SERVED PROCESSING 
800 MB/s 

64 BITS, 100 MHz 
Rev 2.1, 32-BIT, 33M PCI 
READ 96 MB/s, WRITE 88 MB/s 
READ 101 BM/s, WRITE 111 MB/s 
PRIORITY FIRST-COME FIRST- 
SERVED PROCESSING 
200 MB/s 
32 BITS, 50 MHz 



2* Construction and Operation of DoEngine 
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This section describes the outline of the DoEngine as 
well as block diagrams for each of the functional blocks and 
diagrams illustrating general features, detailed features, 
a core interface and timing. 
5 2.1. Chip construction of DoEngine 

Fig. 4 is a block diagram of the DoEngine . The DoEngine, 
indicated at 400, was designed and developed as a controller 
mainly of next-generation multifunction peripherals (MFPs) 
or multifunction systems (MFSs) . A MIPS R4000 core 

10 manufactured by MIPS Technologies, Inc. is employed as a CPU 
(processor core) 401. Packaged in the processor core 401 
are cache memories of 8 KB each for instructions and data, 
an MMU, etc. The processor core 401 is connected to a system 
bus bridge (SBB) 402 via a 64-bit processor bus (P bus) . The 

15 SBB 402 is a 

4 x4 64-bit cross-bus switch and is also connected to a memory 
controller 403, which is for controlling an SDREAM and ROM 
and has a cache memory, via a special -purpose local bus (MC 
bus) , and to a G bus 404, which is a graphics bus, and an 

20 10 bus 405, which is an input/output bus. Thus, the system 
bus bridge 402 is connected to a total of four buses. The 
system bus bridge 402 is connected to these buses on a 
one-to-one basis . To the greatest extent possible the system 
bus bridge 402 is designed in such a manner that the two pairs 

25 of buses can be connected in parallel. 

The G bus 404 is controlled by a G bus arbiter (GBA) 
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406 and is connected to a scanner /printer controller (SPC) 
408 for connecting a scanner and printer. The 10 bus 405 
is controlled by an 10 bus arbiter (BBA) 407 and is connected 
to an SPC 408, a power management unit (PMU) 409, an interrupt 
5 controller (IC) 410, a serial interface controller (SIC) 411 
which uses a UART, a USB controller 412, a parallel interface 
controller (PIC) 413 which uses an IEEE 1284, a LAN controller 
(LANC) 414 which uses an Ethernet, an LCD panel, key, 
general -purpose input/output controller (PC) 415, and a PCI 
10 bus interface controller (PCIC) 416. 

2.2. Processor shell 

The processor shell is a block which includes, in 
addition to the processor core, an MMU (Memory Management 
Unit) , an instruction cache, a data cache, a write-back 
15 buffer and a multiplication unit. 

<Cache memory> 

As shown in Fig. 5, the cache memory controller manages 
a cache in three states, namely invalid, valid clean (the 
cache has not been updated) and valid dirty (the cache has 
20 been updated) . The cache is controlled in dependence upon 
the particular state. 

2.3. Interrupt controller 

Fig. 6 is a block diagram of the interrupt controller 

410. 

25 The interrupt controller 410 is connected to the 10 bus 

405 via an 10 bus interface 605. The interrupt controller 
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410 collects interrupts from each of the function blocks 
within the DoEngine chip and from outside the chip and 
redistributes the interrupts to six levels of external 
interrupts and non-maskable interrupts (NMI) supported by 
5 the CPU core 401. The function blocks are the power 

management unit 409, the serial interface controller 411, 
the USB controller 412, the parallel interface controller 
413, the Ethernet controller 414, the general -purpose 
input /output controller 415, the PCI bus interface 

10 controller 416 and the scanner /printer controller 408. 

It is possible to mask an interrupt for every interrupt 
source by a mask register (Int Mask Logic 0-5) the software 
of which can be configured. As for external interrupt inputs , 
edge sense / level sense can be selected for each signal line 

15 by a selective edge detection circuit 601. A cause register 
(detect and set cause register 0 - 5) 603 indicates, for each 
level, which interrupt has been asserted and, by performing 
a write operation, is capable of performing a clearing 
operation for each level. 

20 The interrupt signal of each level is output as a logical 

sum by an OR circuit 604 in such a manner that an interrupt 
signal is output if there is at least one interrupt for each 
level. It should be noted that level assignment between 
causes within each level is performed by software. 

25 2.4. Memory controller 

Fig. 7 is a block diagram of the memory controller 403 . 
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The memory controller 403, which is connected to the MC bus, 
namely the special -purpose local bus of the memory 
controller, supports a synchronous DRAM (SDRAM) of a maximum 
of 1 GB and 32 -MB flash ROM or ROM. In order to exploit the 
5 characteristic high speed of the SDRAM at the time of burst 
transfer, 64 

(16 x 4) -burst transfer is implemented. Taking into account 
single transfer of continuous addresses from the CPU or 10 
bus, an SRAM (memory front cache) 702 is incorporated within 

10 the main controller and direct single transfer to the SDRAM 
is avoided to the maximum extent to thereby raise the transfer 
efficiency. The data bus width between the memory controller 
and the SDRAM is 72 bits for the signals ramData and ramPar 
(of which the 8-bit signal ramPar is parity) , and the width 

15 of the data buses fntromData, prgromData between the memory 
controller and the flash ROM is 32 bits. 
2.4.2. Construction and operation 

Each portion of the main controller has a construction 
which will now be described. 
20 <MC bus interface (701) > 

The MC bus is a special -purpose bus between the SMM 402 
and the memory controller 403 and is used as the basic bus 
within the SBB. 

The burst transfer of the special-purpose PBus 
25 connecting the CPU 401 and the system bus bridge 402 is 
limited to four bursts, whereas transfers up to 16 bursts 



- 22 - 



X 4 are added on in the MC bus. For this reason, mTType [6:0] 
is defined anew as a signal indicating the burst length. 
{Definition of MC bus signals) 

Each signal of the MC bus is defined as set forth below. 
5 -iridic (output) • • • MC bus clock 

•mAddr[31:0] (output) • • • MC bus address 

Each of these signals is a 32 -bit address and is held 

from the moment mTs__L is asserted to the moment mBRdy_L is 

asserted. 

10 -mDataOut [63 : 0] (output) • • • MC bus data 

output 

This signal is 64-bit output data and is valid only when 
mDataOe_L has been asserted. 

•mDataOe_L (output) • • • MC bus data 

15 output enable 

This signal indicates that signal mDataOut [63 . 0] is 
valid. Further, it indicates that the transfer is Write. 
-mDataIn[63:] (input) MC bus data 

input 

20 This signal is 64-bit input data and is sampled at the 

rising edge of mClk at which mBRdy_L is being asserted. 
*mTs_L (output) • • • MC bus transaction 

start strobe 

This signal indicates that transfer has started. It 
25 is asserted only during the initial clock of the transfer. 
If the transfer ends at one clock and the next transfer starts 
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immediately, mTs_L remains asserted as is. 

•mTType[6:0] (output) • • • MC bus transaction 

type 

This signal indicates the type of transfer on the MC 
5 bus. At the time of single transfer, this signal is held 
during the transfer. At the time of burst transfer, the 
signal is held during the initial transfer (beat) . The three 
higher order bits represent the source (master) and the lower 
order bits the single/burst length. The types are as follows : 



mTTvoe f 6 


:41 


Sianal Source 


001 




CPU 


010 




10 bus 


100 




G bus 


mTType F3 


:01 


Sinale /Burst Lenath 


lxxx 




single (1-8 byte) 


0001 




2 bursts 


0010 




4 bursts 


0011 




6 bursts 


0100 




8 bursts 


0101 




16 bursts 


0110 




2 X 16 bursts 


0111 




3 X 16 bursts 


0000 




4 x 16 bursts 


• mBE_L [ 7 


:0] 


(output) • • • MC bus transaction 



byte enable 

This signal indicates a valid byte lane on the 64-bit 
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data bus at the time of single transfer. At the time of burst 
transfer the signal is valid only for Write and is ignored 
for Read. 

•mBRdy_L (input) • MC bus ready 

5 This signal indicates that the present transfer (beat) 

has ended. 

•mTPW_L (output) • • * Next transaction is 

in-page write 

This signal indicates that the next transfer is a write 
10 on the same page (same row address) . Write can be continued 
up to a maximum of four. Page size is set in a configuration 
register in advance. 

♦mBPWA_L (input) Bus in-page write 

allowed 

15 This signal indicates whether the MC bus slave (memory 

controller) allows an in-page write transaction and is 
sampled at the same clock as that of mBRdy_L. If mBPWA_L 
is de-asserted at this time, mTPW_L is rendered meaningless . 
*mBRty_L (input) Bus retry 

20 This signal is asserted in a case where the MC bus slave 

(memory controller) terminates access without access having 
been executed and indicates that retry must be performed 
after idling for more than at least one cycle. (In a case 
where mBRdy__L andmBRty_L have been accessed simultaneously, 

25 mBRty_L takes priority. ) 

•mBerr_L (input) Bus error 
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This signal is asserted in a case where a parity error 
or other bus error has occurred. 

It should be noted that the above-described indications 
of input/output are definitions as seen only from the SBB. 
5 (MC bus transaction) 

The following transactions are supported as 
transactions on the MC bus: 

(D Basic transaction (1, 2, 3, 4, 8-byte 

Read/Write) 

10 A 1, 2, 3, 4, 8-byte single transaction is supported 

in accordance with mBE_L[7:0] . 
(5) Burst transaction 

A transaction {from the CPU) up to a 4-double-wide burst 
is supported. 

15 (3) A transaction from the G bus up to 16 -double-wide 

burst x 4 is supported* 

@ In-page write transaction 

Continuous write access is supported in regard to the 
same in-page write indicated by mTPW_L. 
20 ® Bus retry 

In a case where memory access cannot be performed owing 
to a limitation within the memory controller, mBRty_L is 
asserted and bus retry is reported, 
< SDRAM controller (705) > 
25 The memory controller 403 controls a SDRAM having the 

following construction in the manner set forth below: 
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{DRAM construction) 

As for DRAM construction, x4, X8, X16 bit type 16/64 
megabit SDRAMs can be 8-bank controlled by a 64-bit data bus . 

TABLE 2 

5 



NUMBER OF DEVICES 
IN BANK 


DEVICE 

CONSTRUCTION 


ROW BITS (BANK 
SELECTION BIT) 
X COLUMN BITS 


BANK SIZE 


MAXIMUM MEMORY 
(8 BANKS) 


16 (64-MBIT TYPE) 


16 M X 4 


14 X 10 


128 MB 


1 GB 


8 (64-MBIT TYPE) 


8 M X 8,9 


14 X 9 


64 MB 


512 GB 


4 (64-MBIT TYPE) 


4 M X 16,18 


14 X 8 


32 MB 


256 GB 


16 (64-MBIT TYPE) 


4 M X 4 


12 X 10 


32 MB 


256 GB 


8 (64-MBIT TYPE) 


2 M X 8,9 


12 X 9 


16 MB 


128 GB 


4 (64-MBIT TYPE) 


1 M X 16,18 


12 X 8 


8 MB 


64 GB 



(DRAM address bit construction) 

With regard to assignment of DRAM address bits , MA [13 : 0] 
is used in case of a 64-bit DRAM and MA[11:0] is used in case 
10 of a 16-bit SDRAM. 

TABLE 3 

64 Mbit SDRAM 



31 30 


29- • -27 


26 25 


24- - -11 


10- - -3 


2- - -0 


0 0 


cs 


C9 C8 


R13- -R0 


C7- - -CO 


BS 


16 Mbit SDRAM 


31 28 


27- —25 


24 23 


22- - -11 


10- - -3 


2- - -0 


0 0 


CS 


C9 C8 


Rll- -RO 


C7- • -CO 


BS 



15 
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0 Zero 

CS Chip Select 

C9 - CO Column Address 

C8 ignored in case of X 8 bit SDRAM 
5 C9, C8 ignored in case of X 16 bit SDRAM 

R13 - RO Row Address 

Rll of 1M SDRAM used in bank select 

in SDRAM, 

With 16M SDRAM, R12, R13 used in bank 
10 select in c as e of 4 -bank arrangement and 

R13 used in bank select in case of 
2 -bank arrangement * 
BS Byte Select 

[SDRAM programmable construction (mode register) ] 
15 The SDRAM has an internal mode register and sets the 

following items using a mode register set command: 
<T) Burst length 

Burst length can be set to any of 1, 2, 4, 8, full page. 
However, since burst transfer length from the CPU is 4, 4 
20 is the optimum burst length. Transfer from the G bus in excess 
of 16 bursts is realized by issuing the Read/Write command 
(without automatic pre-charge) successively. 

(2) Wrap type 

The order in which the address is incremented at the 
25 time of burst transfer is set at this item. Either 
"sequential" or "interleaved" can be set. 
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(3) CAS latency 

Any of 1, 2 or 3 can be set for CAS latency. This is 
decided by the grade of the SDRAM used and the operating 
clock. 

5 (SDRAM command) 

The following commands are supported with regard to the 
SDRAM. The details of each command are described in the SDRAM 
data book. 

•Mode register setting command 
10 -Precharge command 

•Write command 
•Read command 

•CBR (Auto) refresh command 
• Self -refresh start command 
15 -Burst stop command 

•NOP command 
{SDRAM refresh) 

Since the SDRAM is a 2048 cycle / 32 ms (4096/64 ms) 
SDRAM, the CBR refresh command is issued every other 16,625 
20 ns. The memory controller has a settable refresh counter 
and issues the CBR refresh command automatically. A refresh 
request is not accepted during the time that a 16-burst X n 

transfer from the G bus is being carried out. Accordingly, 
a refresh counter must set a value having enough margin with 
25 respect to time for performing the 16-burst x n transfer. 
Further, self-refresh is supported. When this command is 
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issued, self -refresh continues resumes at the time of the 
power-down mode (ramclke__L = Low) . 
(SDRAM initialization) 

The memory controller initializes the SDRAM, in the 
5 manner set forth below, after power-on reset. Specifically, 
after a pause of 100 \is following introduction of power, the 
memory controller 

(1) precharges all banks using the precharge command; 

(2) sets the mode register of the SDRAM; and 

10 (3) performs refresh eight times using the auto-refresh 

command. 

<Flash ROM controller (704) > 

A flash ROM controller 704 supports an address signal 
romAddr[23:2] and four chip-select (romCs_L[3 : 0] signals. 

15 Address signals romAddr2 - romAddr9 are multiplexed with 
parity signals ramParO - ramPar7, and address signals 
romAddrlO - romAddrw23 are multiplexed with DRAM addresses 
ramAddrO - ramAddrl3 . 

<SRAM control (memory front cache )> 

20 An SDRAM used as a main memory provides very high burst 

transfer speed but such high speed cannot be achieved in case 
of a single transfer. Accordingly, a memory front cache is 
packaged within the memory controller to speed up single 
transfer. The memory front cache is composed of a cache 

25 controller 706 and an SRAM 702. Since the transfer master 
and transfer length can be ascertained by the mTType[6:0] 
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signal defined for the MC bus, cache ON/OFF can be set for 
every master or for every transfer length. The cache schemes 
are as set forth below. It should be noted below that, unless 
stated otherwise, the term "simple cache" or "cache memory" 
5 refers not to a cache incorporated within the processor core 
but to a memory front cache incorporated in the main 
controller. 

•2 -way set associative 

•8-KB data RAM 
10 -128 X 21 X 2 Tag RAM 

•LRU (Least Recently Used) algorithm 

•Write- thru 

•No write allocate 

Cache operation in a case where a memory read/write 
15 transfer has been requested from an MC bus will be described 
with reference to the block diagram of Fig. 8 and the 
flowcharts of Figs. 9 and 10. 

If data transfer from an MC bus starts, it is judged 
whether the transfer is perf ormed with cache ON or with cache 
20 OFF depending upon mTType[6:0] indicated on the MC bus at 
the start of the transfer. In this description, the ON 
decision is rendered if the transfer is single transfer and 
the OFF decision is rendered if the transfer is burst transfer 
(step S901) . That is, if mTType(3) is "l"h, this represents 
25 single transfer and, hence, the transfer is performed with 
the cache ON. If mTType(3) is "0"h, this represents burst 
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transfer and, hence, the transfer is performed with the cache 
OFF. 

If address Imaddr [31 : 0] is applied in case of single 
transfer (cache ON) , then it is applied to bl_tag_rain 801, 
5 b2_tag_ram 802, bl„data_ram 7 02 -a, b2_data_ram702-b and lru 
803 with Imaddr [11:5] serving as the index, and valid bit 
"v" and bl_tag_addr"; valid bit "v" and b2_tag_addr; 
bl_out_data; b2_out_data; and lru_in, which correspond to 
the entered index, are output from the respective blocks 

10 (step S902) . 

Next, bl_tag_addr and b2__tag_addr output by bl_tag_ram 
801 and b2_tag_ram 802 are compared with the address 
Imaddr [31:12] by a bl_comparator 804 and b2_comparator 805. 
The result, namely hit or miss, is reported to the cache 

15 controller 706 by bl_hit__miss_L, b2_hit__missL signals, 
whereby hit or miss is judged (step S903) . 

In case of a hit, read or write is determined (step 
S904) . If a hit is detected, this is a case where the address 
Imaddr [ 3 1 : 12 ] agrees with either bl_tag_addr or b2_tag__addr . 

20 If a hit is detected and then read is determined, operation 
is as follows: If bl is a hit and the requested transfer 
is read, bl_out_data is selected of bl_out_data and 
b2_out_data that have already been read out, and 8-byte data 
indicated by Imaddr [4 : 3 ] is output to the MC bus (step S905) . 

25 At the same time, lru corresponding to this index is rewritten 
as "0" (= bl hit) and the transfer is terminated. If b2 is 
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a hit and the requested transfer is read, b2_out_data is 
selected of bl__out_data and b2_out_data that have already 
been read out, and 8-byte data indicated by lmaddr[4:3] is 
output to the MC bus (step S905) . At the same time, lru 
5 corresponding to this index is rewritten as "l n h (= b2 hit) 
and the transfer is terminated. 

On the other hand, if a hit is detected and then write 
is determined, operation is as follows: If bl is a hit and 
the requested transfer is write, then, of the 8-byte data 

10 indicated by lmaddr[4.3] of bl_data_ram 

702-a indicated by the index, only a valid byte lane indicated 
by mBE_L[7.0] is rewritten. At the same time, lru 
corresponding to this index is rewritten as "0"h (= bl hit) . 
Further, the SDRAM also is rewritten and transfer is 

15 terminated in similar fashion (step S906) . If b2 is a hit 
and the requested transfer is write, then, of the 8-byte data 
indicated by lmaddr[4.3] of b2_data_ram 702-b indicated by 
the index, only a valid byte lane indicated by mBE_L[7.0] 
is rewritten. At the same time, lru corresponding to this 

20 index is rewritten as "l"h (= b2 hit) . Further, the SDRAM 
also is rewritten and transfer is terminated in similar 
fashion (step S906) . 

If bl and b2 are both misses, on the other hand, a read 
or write judgment is rendered (step S1001) . If the requested 

25 transfer is read, 8-byte data indicated by lmaddr[31:3] is 
read out of the SDRAM (step S1003) and is output to the MC 
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bus (step S1004) . At the same time, lru corresponding to 
this index is read out. If lru is "0 M h, data from the SDRAM 
is written to b2__data_ram and lru also is rewritten as "l"h. 
If lru is "1% data from the SDRAM is written to bl_data_ram 
5 and lru also is rewritten as "0"h (step S1005) , after which 
the transfer is terminated. If bl and b2 are both misses 
and the requested transfer is write, the data is merely 
written to the SDRAM and the transfer is terminated (step 
S1002). % 

10 In case of a burst transfer (cache OFF) at step S901, 

read is carried out only with respect to the SDRAM (steps 
S907, S909) and rewriting of cache data or tags is not 
performed. In case of burst write, it is determined whether 
or not data corresponding to the write address is cached in 

15 a cache line. When it is determined that the data is cached, 
a valid bit of the cache line is cleared and the cache line 
is invalidated. 

<ROM/RAM interface (707)> 

Fig. 11 illustrates the construction of the ROM/RAM 
20 controller 707. An SDRAM data signal, address signal and 
parity signal are multiplexed with the data signal and 
address signal of a flash ROM by blocks 1101 through 1104. 
2.4.3. Timing diagrams 

The timing of processing, such as data read and write, 
25 by the memory controller 403 set forth above will be described 
with reference to Figs. 12 through 19. 
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Fig. 12 shows the timing of burst readout from the CPU. 
The burst length is 4 and the CAS latency is 3. This 
corresponds to the processing at step S909 in Fig. 9. 

Fig. 13 shows the timing of burst write from the CPU. 
5 The burst length is 4 and the CAS latency is 3. This 
corresponds to the processing at S908 in Fig. 9. 

Fig. 14 shows the timing of burst readout from the G 
bus device. The burst length of the G bus is 16, the burst 
length of the SDRAM is 4 and the CAS latency is 3. This 
10 corresponds to the processing at S909 in Fig. 9. 

Fig. 15 shows the timing of burst write from the G bus 
device. The burst length of the G bus is 16, the burst length 
of the SDRAM is 4 and the CAS latency is 3 . This corresponds 
to the processing at S908 in Fig. 9. 
15 Fig. 16 illustrates the timing of single readout in case 

of a hit in the memory front cache. Here bl/b2_out_data, 
which has been read out of the cache memory bl_data_ram 7 02 -a 
or b2_data_ram 702 -b, is output as data mDataIn[63 : 0] to be 
read out. The burst length of the SDRAM is 4 and the CAS 
20 latency is 3. This corresponds to the processing at step 
S905 in Fig. 9. 

Fig. 17 illustrates the timing of single readout in a 
case where there is no hit in the memory front cache. Data 
ramData [ 63 : 0 ] , which has been read out of the SDRAM, is output 
25 as data mDataln [63 : 0] to be read out. This data is written 
also to cache memory bl_data_ram 7 02 -a or b2_data_ram 702-b 
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as bl/b2_in_data. The burst length of the SDRAM is 4 and 
the CAS latency is 3. This corresponds to the processing 
at steps S1004 and S1005 in Fig, 10. 

Fig. 18 illustrates the timing of single write in case 
5 of a hit in the memory front cache. Data mDataOut [63 : 0] to 
be written is written to cache memory bl__data_ram 7 02 -a or 
b2_data_ram 702-b and to the SDRAM as well . The burst length 
of the SDRAM is 4 and the CAS latency is 3 . This corresponds 
to the processing at step S906 in Fig. 9. 

10 Fig. 19 illustrates the timing of single write in a case 

where there is no hit in the memory front cache. Data 
mDataOut [63 :0] to be written is written only to the SDRAM 
and not to cache memory bl__data_ram 7 02 -a or b2_data__ram 
702-b. The burst length of the SDRAM is 4 and the CAS latency 

15 is 3. This corresponds to the processing at step S1002 in 
Fig. 10. 

When data transfer is started from the MC bus, the cache 
ON is decision is rendered if the transfer is single transfer 
and the cache OFF decision is rendered if the transfer is 

20 burst transfer, depending upon mTType [ 6 : 0 ] indicated on the 
MC bus at the start of the transfer. However, an arrangement 
may be adopted in which, in the case of the burst transfer, 
the burst length is discriminated and cache ON is construed 
if the burst length is smaller than one line of the cache, 

25 with cache OFF being decided otherwise. 

By including on the MC bus a signal that indicates the 
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identifier of the bus master than requested the data transfer 
to the memory, the memory controller can discriminate this 
identifier and control the cache ON/OFF operation in 
dependence upon the identifier. In this case a rewritable 
5 table that maps identifiers and cache ON/OFF can be provided 
and cache ON/OFF can be changed over by referring to the 
table. This table can be rewritten from the CPU 401 
by allocating specific addresses, etc. 

2.5. System bus bridge (SBB) and 10 bus, G bus 
10 Fig. 20 is a block diagram of the system bus bridge (SBB) 

402. 

The SBB 402 is a multichannel bidirectional bus bridge 
which provides the interconnection among the 10 bus 
(input/output bus), G bus (graphics bus), P bus (processor 
15 local bus) and MC bus by using a cross -bus switch. By virtue 
of the cross-bus switch, the connections of two systems can 
be established simultaneously and it is possible to realize 
high-speed data transfer with a high degree of parallel 
operation. 

20 The SBB402, besides having an 10 bus interface 2906 for 

connecting the 10 bus 405, a G bus interface 2006 for 
connecting the G bus 404, a CPU interface slave port 2002 
for connecting the processor core 401 and a memory interface 
master port for connecting the memory controller 403, also 

25 includes an address switch 2003 for connecting an address 
bus and a data switch 2004 for connecting a data bus. The 
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SBB 402 further includes a cache invalidation unit 2005 for 
invalidating the cache memory of the processor core. 

A write buffer for speeding up DMA writing from the 10 
bus device and read prefetch queues for raising the 
5 efficiency of the reading of the 10 bus device are packaged 
in the 10 bus interface 2009. Coherency management relating 
to data that exists in these queues temporarily is performed 
by hardware. It should be noted that a device connected to 
the 10 bus is referred to as a "device". 

10 The processor core supports dynamic bus sizing in regard 

to a 32-bit bus. However, this is not supported by the SBB 
402. The reason is to minimize necessary modification of 
the SBB in a case where a processor core that does not support 
bus sizing is used in the future. 

15 <I0 bus interface> 

Fig. 21 is a block diagram of the 10 bus interface 
The 10 bus interface 2009 is a bidirectional bridge 
circuit between the 10 bus and the MC bus. The 10 bus is 
an internal general-purpose bus of the DoEngine. 

20 Five blocks, namely a master control block 2011, slave 

control block 2010, data interface 2012, DMAC 2013 and 10 
bus buffer, are included in the 10 bus interface 2009. In 
Fig. 21, the DMAC 2013 is partitioned functionally into three 
sequencers and register blocks. Among the three sequencers, 

25 a DMA memory access sequencer is incorporated within the 10 
bus slave control block 2010 and a DAM reg sequence is 
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incorporated within the 10 bus master control block 2011. 
A DMA register, which is a register block, is incorporated 
within the 10 bus data interface 2012. 

The 10 bus interface 2009 controls invalidation of both 
5 data and instruction caches in the CPU shell via a cache 
invalidation interface when a write is performed from the 
10 bus side to the memory and when a transfer is made from 
a device to a memory by DMA. 

Though a write-back buffer for when CPU write is 

10 performed is not packaged in the 10 bus interface, a write 
buffer for external master write on the 10 bus is packaged 
in the 10 bus interface. As a result, continuous write from 
an external master, which is not burst transfer, is speeded 
up. Flashing of this write buffer is performed when 

15 connection to the memory is allowed by the 10 bus arbiter 
407. Write buffer bypass of the 10 bus master read is not 
carried out. 

Further, read prefetch queuing of the external master 
is executed. As a result, continuous readout of a data stream 
20 from an external master is speeded up. Invalidation of the 
read buffer is performed 

1. when new reading of the 10 bus has not produced hit 
in the buffer; 

2. when write from the CPU to the memory has been 
25 performed; 

3 . when write from the G bus to the memory has been 
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performed; and 

4. when write from the 10 bus to the memory has been 
performed . 

The DMA controller 2013 between each device on the 10 
5 bus 405 and the memory is incorporated within the 10 bus 
interface 2009. By incorporating a DMA controller in the 
system bus bridge 402, access requests can be issued to the 
bridge in both directions simultaneously and efficient DMA 
transfer can be implemented. 
10 The 10 bus interface 2009 does not require use of dynamic 

bus sizing in response to an access request from the processor 
401 and does not support bus sizing from the memory controller 
403 when there is a memory access request from the 10 bus 
master. In other words, the memory controller should not 
15 expect bus sizing. 
<I0 bus> 

The 10 bus is a general-purpose bus within the DoEngine 
and has the following specifications: 

•address, data discrete-type 32-bit bus 
20 *any weight cycle insertable; shortest is no wait 

•supports burst transactions 

•maximum transfer speed is 200 MB/s when clock 
is 50 MHz 

•supports bus error and bus retry 
25 -supports plural bus masters 

(10 bus signal definition) 
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The definition of bus signals will now be described* 
The format of the descriptions will be "signal name (in 
English) : input source > output destination, (3 State) * • • 
description of the signal". It should be noted that the "3 
5 States" item is limited to a 3 -state signal. 

bAddr[31:2] (10 Bus Address Bus): Master > Slave, 3 
State • • • 10 Bus address bus 

bData[31:0] (10 Bus Data Bus): DataDriver > 
DataReceiver, 3 State • • « 10 Bus data bus 
10 b(Datadrivername) DataOeReq (IOBus Data Output Enable 

Request) : Datadriver>Defau It Driver Logic • • - This is an 
output signal to default driver control logic for the purpose 
of realizing a bidirectional 10 bus, described later. This 
is a request signal for driving data on the bus by a device 
15 having Datadrivername ♦ b (Datadrivername) Data0e_L is output 
from default driver control logic to a device for which output 
of data has been allowed. Examples of Datadriver are Pci, 
Sbb, Jpeg, Spu, etc. 

b (Datadrivername )Data0e__L (IOBus Data Output Enable) : 
20 dfaultDriverLogic > Datadriver • • • In a case where default 
driver logic allows drive of data to the data bus in regard 
to a device that has output b (Datadrivername) DataOeReq, the 
b (Datadrivername) Data0e_L signal is sent back to this 
device . 

25 bError_L (IOBus Bus Error) : Slave > Master, 3 State 

• * • This signal indicates that an 10 bus transaction has ended 
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in an error. 

b(Mastername)BGnt_L (IOBus Grant): Arbiter > Master 
• * * Indicates that this master has obtained the privilege 
to use the bus by a bus arbiter transaction. Examples of 
5 Mastername are Pci, Sbb, Jpeg, Spu, etc. 

blnstNotData (IOBus Instruct ion /Data Output 
Indicator) : Master > Slave, 3 State * — In a case where the 
10 bus master performs an instruction fetch with regard to 
the 10 bus slave, this signal is driven high. In case of 
10 a data transaction, the signal is driven low. 

b (Mastername) CntlOeReq (IOBus Master Control Output 
Enable Request) : Master > DefaultDriverLogic • • • In a case 
where the 10 bus master wishes to drive signals bStart_L, 
bTx_L, bWr_L,vInstNotData and bAddr[31:2] on a 3 -state bus, 
15 this signal is asserted in regard to IOBus Output Control 
Logic. Based upon bMCntlOeReq, 10 Bus Output Control Logic 
sends signal b (Mastername) CntlOe_L, from each master, back 
to the master which allows drive. 

b (Mastername )Cntl0e_L (IOBus Master Control Output 
20 Enable) : DefaultDriverLogic > Master — • In a case where 
default driver logic allows drive of a signal in regard to 
a master that has output b (Mastername) CntlOeReq, the 
b (Mastername) Cntl0e_L signal is sent back to this master. 

bRdy_L (IOBus Ready) : Slave > Master, 3 State • • • The 
25 10 bus slave asserts this signal in order to indicate that 
the present 10 bus data transaction will end at the present 
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clock cycle. The 10 bus master ascertains from this signal 
that the present transaction will be ended by this clock 
cycle. 

b (Mastemame) BRecL_L (IOBus Bus Request) : Master > 
5 Arbiter • * • Indicates that the 10 bus master has requested 
bus use privilege of the 10 bus arbiter. 

bRetry_L (IOBus Bus Retry) : Slave > Master, 3 State 
* • • Requests re-execution of the bus transaction. 

b(Slavename)RdyOeReq (IOBus Slave Ready Output Enable 
10 Request) : Slave > Def aultDriverLogic • • • In a case where 
the 10 bus slave wishes to drive bRdy__L, bWBurstReq_L, 
bBurstAck__L on a 3 -state bus, this signal is asserted in 
regard to IOBus Output Control Logic. Based upon 
b(Slavename) RdyOeReq, 10 Bus Default Driver Logic sends 
15 signal b(Slavename)RdyOe_L, from each master, back to the 
slave which allows drive. 

b(Slavename)RdyOe_L (IOBus Slave Ready Output Enable) : 
Def aultDriverLogic > Slave • • • In a case where default driver 
logic allows drive in regard to a master that has output 
20 b(Slavename) RdyOeReq, the b(Slavename) RdyOe_L signal is 
sent back to this master. 

bSnoopWait (IOBus Snoop Wait) : SBB > NextMaster: 
Indicates that the 10 bus interface is currently executing 
cache snooping in regard to another device connected to the 
25 IO bus. The device connected to the 10 bus cannot issue a 
new transaction while this signal is being asserted. 
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bStart_L (IOBus Transaction Start) : Master' > Slave, 
3 State • • * This is a signal which indicates that the 10 bus 
master starts an 10 bus transaction. By monitoring this 
signal, the 10 bus slave can ascertain start of an 10 bus 
5 transaction. 

bTx_L (IOBus Transaction Indicator Input) : Master > 
Slave, 3 State This signal is asserted in order to 
indicate that the 10 bus master is currently executing an 
10 bus transaction with respect to the 10 bus slave. 
10 bWBurstGnt_L (10 Bus Burst Write Grant) : Master > 

Slave, 3 State * * * This signal is driven in order to indicate 
that the 10 bus master executes burst write in response to 
a request for 10 bus burst write. 

bWBurstGnt_L (10 Bus Burst Write Request) : Slave > 
15 Master, 3 State * • * This signal is asserted in a case where 
the 10 bus slave requests burst write in regard to an 10 bus 
master. 

bWr_L (IOBus Write Transaction Indicator) : Master > 
Slave, 3 State • • • This signal is asserted in order for the 
20 10 bus master to indicate that the present transaction is 
a write in regard to the 10 bus slave. 

bByteEn[3 : 0] (10 Bus Byte Enables) : Data Driver > Data 
Receiver, 3 State • • • This signal is driven high in order 
for an agent which drives data on the 10 bus to indicate that 
25 a byte lane onbData[31: 0] corresponding to each bit is valid. 
Each line of this signal and the byte lane of the bData are 
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related as shown in Table 4. 



5 TABLE 4 



Byte Enable 


Corresponding bData [31:0] 


bByte En3 


[31:34] 


bByte En2 


[23:16] 


bByte Enl 


[15:8] 


bByte EnO 


[7:0] 



bBurst_L (10 Bus Extented Burst Request) : Master > 
Slave, 3 State • • * Indicates that the 10 bus master wishes 
10 to perform an extended burst. Assert and negate timings are 
the same as bTx__L. 

bBurstAck_L (10 Bus Extended Burst Acknowledge) : Slave 
> Master, 3 State • • • Indicates that the 10 bus slave can 
perform an extended burst. Assert and negate timings are 
15 the same as bRdy__L. 

bBurstShortNotLong_L (10 Bus Burst Length) : Master > 
Slave, 3 State • • • Indicates burst length in a case where 
the 10 bus master performs an extended burst. Assert and 
negate timings are the same as bTx__L. The correspondence 
20 between signal values and burst lengths are shown in Table 
5. 

TABLE 5 
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bBurst Short Not Loner L 


Burst Length 


H 


4 beats 


L 


8 beats 



The 10 bus signals are as set forth above. Since the 
10 buses (and G buses) , which are the internal buses of the 
DoEngine, are such that the number of function blocks that 
5 can be connected is ten or more, it is difficult to connect 
all blocks the InOut discrete buses. In-chip bidirectional 
buses are employed in DoEngine. 

<G bus interface> 

Fig. 22 is a block diagram of the G bus interface 2006. 
10 An overview of this interface will now be described. 
(Outline of G bus) 

The G bus is a bus defined in order to execute data 
transfer between the image data processors at high speed 
within a single-chip controller DoEngine for MFP. The G bus 

15 possesses a 64-bit data bus and supports an address space 
of 4 GB (12 8-byte boundary) . The basic transfer is such that 
16 beats (128 bytes = 64 bits X 16) is adopted as one long 
burst, and up to four successive long bursts (512 bytes = 
16 beats x 4) are made possible. (A transfer of less than 

20 16 beats, such as a single beat, is not supported.) 
(G bus signal definition) 

The symbols used in defining the signals are determined 
first. The direction of the signal is described as necessary 
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immediately after the signal name. The determinations are 
made as follows: 

In (Input signal) input signal to bus agent 

Out (Output signal) • • • output signal from bus 
5 agent 

InOut (Bidirectional tri-state signal) • • • 

bidirectional signal 
A plurality of agents perform drive by these signals. Only 
one agent performs drive at one time. Enable request signals 

10 of the agents which drive the signals are centrally managed 
by the default driver, and the default driver decides which 
agent performs drive. Default driver signals are driven in 
a case where no agents issue enable requests or in a case 
where a plurality of agents are issuing enable requests 

15 simultaneously. In a case where a signal is driven low, the 
agent must perform drive high for one clock before and after. 
Assertion of the signal is carried out only after elapse of 
one clock from start of drive. Release of the signal 
basically is performed at the next clock negated. 

20 it should be noted that the "L" after each signal name 

indicates that the signal is low active. The description 
of the signals is substantially in line with the description 
of the 10 bus signals. This description will be divided into 
descriptions of system signals, address and data signals, 

25 interface control signals and arbitration signals. The bus 
agent is the generic term for a bus master or bus slave 
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connected to the bus. 
(System signals) 

gClk (G-Bus Clock) • • • Provides the timing of all 
transactions on the G bus and is an input to all devices . 
5 gRst_L (G-Bus Reset) All devices on the G bus are 

reset by this signal. All internal registers are cleared 
and all output signals are negated. 
(Address and data signals) 

gAddr[31:7] , InOut, (G-Bus Address): Master > Slave 
10 Supports 4 GB of address space at 25 bits of gAddr[31] 

- gAddr [7] because all data transfer on the Gbus is performed 
in units of 128 bytes {16 bits) . Signal is driven by the 
master at the same time as drive :gTs_L. The timing at which 
this signal is asserted is the next clock following drive, 
15 and the timing at which this signal is negated is that of 
the clock at which the assertion of the signal gAack_L was 
verified. 

g(Mastername)AddrOeReq (G-Bus Address Output Enable 
Request) : Master > Default Driver Logic • • • This signal is 
20 the output signal to the default driver logic in order to 
realize a bidirectional G bus. It is a request signal by 
which the bus master drives the address bus. 

g(Mastername)AddrOe_L (G-Bus Address Output Enable): 
Default Drive Logic > Master • • • This is a signal which 
25 indicates, to the bus master that output 

g(Mastername) AddrOeReq, that the default driver logic allows 
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address bus drive, 

gData[63:0] , InOut, (G-Bus Data) : Data Driver > Data 
Receiver In case of a 64-bit data bus, this signal is 

driven by the master at the time of a write operation and 
by the slave at the time of a read operation. Timing when 
driven and assert, change and negate timings are as follows: 

[Write] 

drive: Driven by master at same time as gTs_L . However, 
when gSlvBsy_L is being asserted, the signal is driven after 
waiting for gSlvBsy_L to be negated. 

assert: Asserted at the next clock following drive, 

change: Clock at which assertion of gAack_L was 
verified, and then every clock thereafter. 

negate: Negated at the clock at which assertion of 
gAack_L was verified when transfer ends or in a case where 
a transfer termination request by gTrStp__L was verified. 

[Read] 

drive: Driven by slave at same time as gAack_L. 

assert: Asserted at the next clock following drive if 
the slave is ready. If the slave is not ready, the signal 
is asserted after waiting for the slave to be ready. 

change: Clock at which assertion of gAack_L was 
verified, and then every clock thereafter. In case of read, 
every clock from clock asserted. 

negate: When transfer is terminated. 

release: One clock after negation or clock when 
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transfer termination request by gTrStp_L was verified. 

g{DataDrivername)DataOeReq (G-Bus Data Output Enable 
Request) : Data Driver > Default Driver Logic • • • Request 
signal by which data driver drives data bus. 
5 g(DataDrivername)DataOe_L (G-Bus Data Output Enable) : 

Default Drive Logic > Data Driver • • • This is a signal which 
indicates, to the data driver that output 
g(DataDrivername)DataOeReq, that the default driver logic 
allows address bus drive. 

10 (Interface control signals) 

gTs_L (InOut G-Bus Transaction Start) : Master > Slave 
* - • This signal, which is asserted low for one clock by the 
master, represents the start of transfer (the address phase) . 
The master drives gAddr, gRdNotWr, gBstCnt together with 

15 gTs_L and clarifies the type of transfer and the quantity 
of data. In case of a write operation, the master must assure 
that the clarified transfer data quantity is issued without 
waiting. In case of a read operation, the master must assure 
that the clarified transfer data quantity is received without 

20 waiting. In a case where the slave can no longer perform 
data transfer in mid-course, there are instances where the 
next 16-bit transfer is canceled by gBsStep_L. However, 
transfer is never canceled in the middle of 16 bits. 

drive: Driven at a clock at which assertion of gGnt„L 

25 was verified. 

assert: Asserted by the next clock following drive. 
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negate: Negated one clock after assert. 
g(Mastername)TsOeReq (G-Bus Transaction Start Output 
Enable Request) : Master > Default Driver Logic • • • Request 
signal by which bus master drives gTs_L. 
5 g(Mastername)TsOe_L (G-Bus Transaction Start Output 

Enable) : Default Driver Logic > Master — Signal which 
indicates, to bus master that output g(Mastername)TsOeReq, 
that the default driver logic allows drive of gTs_L. 

gAackJL, InOut, (G-Bus Address Acknowledge) : Slave > 

10 Master • • * Driven low for one clock by the slave. The slave 
recognizes the transfer, confirms that the bus is idle and 
notifies the master that the data transfer can start. In 
the case of a write operation, the slave must assure that 
a requested transfer data quantity can be received from the 

15 master without waiting. In the case of a read operation, 
the slave must assure that the requested transfer data 
quantity can be issued without waiting. In the event that 
a data transfer can no longer be performed in mid-course, 
the next 16-bit transfer can be canceled by gBstStp_L. 

20 However, transfer is never canceled in the middle of 16 bits . 

drive: At the time of an address decode bit, drive is 
started at the clock at which assertion of gTs__L was verified. 
However, when gSlvBsy_L is being asserted, the signal is 
driven after waiting for gSlvBsy_L to be negated. In a case 

25 where the signal could not be driven because the data bus 
was in use, drive starts at the clock at which a transfer 
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termination request by gTrStp_L was verified. 

assert: Asserted at the next clock following drive if 
the slave is ready. If the slave is not ready, the signal 
is asserted after waiting for the slave to be ready. When 
5 there is a response to transfer termination by gTrStp_L, the 
signal is asserted at the next block driven. 

negate: In a case where gTrStp_L is asserted after 
drive, the signal is asserted at the clock at which gTrStp_L 
was verified. The signal is negated one clock after assert. 
10 g(Slavename)AackOeReq (G-Bus Address Acknowledge 

Output Enable Request): Slave > Default Driver Logic 
Request signal by which slave drives gAack_L. 

g(Slavename)AackOe_L (G-Bus Address Acknowledge 
Output Enable) : Default Driver Logic > Slave • • * Signal which 
15 indicates, to slave that output g (Slavename) AackOeReq, that 
the default driver logic allows drive of gAack__L. 

gSlvBsy_L, InOut, (G-Bus Slave Busy) : Slave > Master 
• • * Indicates that the slave performs drive and that data 
is being transferred by the data bus. 
20 drive: At the time of an address decode bit, drive is 

started at the clock at which assertion of gTs_L was verified. 
However, when gSlvBsy_L is being asserted, the signal is 
driven after waiting for gSlvBsy_L to be negated. 

assert: Asserted at the next clock following drive if 
25 the slave is ready. If the slave is not ready, the signal 
is asserted after waiting for the slave to be ready. 



- 52 - 



negate: Negate at end of transfer. 

release: One clock after negation or clock when 
transfer termination request by gTrStp_L was verified. 

g(Slavename) SlvBsyOeReq (G-Bus Slave Busy Output 
5 Enable Request) : Slave > Default Driver Logic • • • Request 
signal by which data slave drives gSlvBsy_L. 

g(Slavename) SlvBsyOe_L (G-Bus Slave Busy Output 
Enable) : Default Driver Logic > Slave • • • Signal which 
indicates, to slave that output g (Slavename) SlvBsykOeReq, 
10 that the default driver logic allows drive of gSlvBsy_L. 

gRdNotWr, InOut, (G-Bus Read (High) /Write (Low)): 
Master > Slave * • • This signal is driven by the master and 
represents READ when high and WRITE when low. The period 
during which drive is performed is the same as GA. 
15 drive: Master performs drive at the same time as gTs_L . 

assert: Next clock driven. 

negate: Clock at which assertion of gAack_L was 
verified. 

g(Mastername)RdNotWrOeReq (G-Bus Read/Write Output 
20 Enable Request) : Master > Default Driver Logic • * • Request 
signal by which the bus master drives gRdNotWr. 

g(Mastername)RdNotWrOe_L (G-Bus Read/Write Output 
Enable) : Signal which indicates, to bus master that output 
g(Mastername)RdNotWrOeReq, that the default driver logic 
25 allows drive of gRdNotWr. 

gBstCnt[l:0] , InOut, (G-Bus Burst Counter) : Master > 
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Slave • • • This signal is driven by the master and represents 
the number (1-4) of burst transfers performed in succession. 
The correspondence between the signal values and the number 
of bytes in burst transfer is shown in Table 6. 
5 drive: Master performs drive at the same time as gTs_L . 

assert: Next clock following drive, 
negate: Clock at which assertion of gAack_L was 
verified. 



10 TABLE 6 



gBstCnt[l:0] 




Number of bytes transferred 


01 


16 beats X 1 


64 bits x 16 x 1 = 128 bytes 


10 


16 beats X 2 


64 bits X 16 X 2 = 256 bytes 


11 


16 beats X 3 


64 bits X 16 X 3 = 384 bytes 


00 


16 beats x 4 


64 bits x 16 X 4 = 512 bytes 



g(Mastername)BstCntOeReq (G-Bus Burst Counter Output 
Enable Request) : Master > Default Driver Logic • • • Request 
15 signal by which the bus master drives gBstCnt. 

g(Mastername)BstCntOe_L (G-Bus Burst Counter Output 
Enable): Default Driver Logic > Master Signal which 

indicates, to bus master that output 

g(Mastername)BstCntOeReq, that the default driver logic 
20 allows drive of gBstCnt. 

gBstStp__L, InOut, (G-Bus Burst Stop) : Slave > Master 
* * - This signal is driven by the slave and indicates that 
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acceptance of the next successive burst transfer is not 
allowed. The signal is asserted at the 15th beat of one burst 
(16 beats) . Not driven if not stopped. 

drive: 14th beat 
5 assert: 15th beat 

negate: One clock after assert 

g(Slavename)BstStpOeReq (G-Bus Burst Stop Output 
Enable Request) : Slave > Default Driver Logic • • • Request 
signal by which slave drives gBstStp_L. 
10 g(Slavename)BstStpOe_L (G-Bus Burst Stop Output 

Enable) : Default Driver Logic > Slave • • • Signal which 
indicates, to slave that output g (Slavename) BstStpOeReq, 
that the default driver logic allows drive of gBstStp_L. 

(Arbitration signals) 
15 g(Mastername)Req_L, Out, (G-Bus Request) : Master > 

Arbiter • • • This signal is driven by the master and request 
the arbiter for a bus . The signal possesses a special-purpose 
gReq_L for each master device. 

assert: Master necessary for the data transfer asserts 
20 the signal. 

negate: Negated if gGnt_L is received. 

g(Mastername)Gnt_L, In, (G-Bus GNT) : Arbiter > Master 
• * • This signal is driven by the arbiter and grants the next 
bus privilege in response to a bus request. The signal 
25 possesses a special -purpose gGnt for each master device. The 
signal grants bus privileges in regular order starting from 
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the bus master having the highest priority. With regard to 
masters having the same priority, the signal grants bus 
privilege in the order in which bus requests were issued. 

assert : This signal is asserted with respect to a master 
5 selected by arbitration when gGnt_L has not been granted to 
another master or when gGnt_L, which has been granted to 
another master, is negated by the next clock. 

negate: Clock at which assertion of gAacK was verified. 

gTrStp_L, In, (G-Bus Transaction Stop) : Arbiter > 
10 Master, Slave « • • This signal is driven by the arbiter in 
order to suspend a transaction for which an address phase 
has already been started by gGnt_L. However, a transaction 
for which a data phase has already been started by gAack_L 
cannot be suspended. Further, this signal is masked by 
15 gAack_L. When gAack_L has been asserted, the signal is 
negated and output even though asserted. 

assert: Asserted when a bus request has arrived from 
a master having a priority higher than that of the transaction 
for which the address phase has already started. 
20 negate: Clock at which assertion of gAack_L was 

verified. 

(G-bus write cycle) 

The G-bus write cycle is as follows: 
® The master issues a bus request and asserts gReq_L. 
25 ® The arbiter grants permission, asserts gGnt__L and 

negates gReq_L. 
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(3) The master receives gGnt_L and drives gTs_L , gAddr, 
gRdNotWr, gBstCnt. In case of a write operation, the master 
also drives gData simultaneously if gSlvBsy__L has not been 
asserted. If gSlvBsy_L is being driven, the master performs 
5 drive upon waiting for gSlvBsy_L to be freed. 

® The slave decodes the address when gTs_L has been 
asserted. If is hit occurs, i.e., if a decoded address is 
the device's own address, the device recognizes the transfer 
to itself. If gSlvBsy_L has not been asserted by another 

10 slave at this time, drive of gSlvBsy_L and gAack is started. 
In case of a read operation, gData is driven as well. If 
gSlvBsy_L has been asserted by another slave, this means that 
the data bus is currently in use. Drive is started, 
therefore, upon waiting for this signal to be negated. If 

15 the slave can make preparations for data transfer following 
the start of drive of gSlvBsy_L, gAack_L, (gData) , then each 
of these signals is asserted and data transfer is begun. 

® The address phase ends and the master negates gAddr, 
gRdNotWr, gBstCnt at the moment gAack_L is asserted. At this 

20 time, moreover, the master changes over the write data every 
clock and transfers only the amount of data specified by 
gBstCnt. The master and slave must become aware of the end 
of data transfer by counting the clock themselves . 

In a case where the slave can no longer transfer the 

25 requested amount of data from the master in the middle of 
a transfer, the slave asserts bStStp_L at the 15th bit, 
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thereby canceling the transfer of the next 16 bits. 'However, 
cancellation in the middle of 16 bits cannot be carried out* 

If the master and slave have asserted gBstStp_L, 
transfer of data must be finished at the next clock. 
5 <Cache Invalidation Unit (CIU)> 

The cache invalidation unit (referred to as a "CIU" 
below) 2005 monitors a write transaction from the 10 bus to 
the memory. If a write transaction occurs, the CIU 
invalidates the cache, which is incorporated within the CPU 
10 shell, using the cache invalidation interface of the CPU 
shell before the write to the memory is finished. 

The CPU shell uses the following three types of signals : 
•SnoopADDR[31:5] (Cache Invalidation Address) 
•DCINV [Dcache (data cache) Invalidation Strobe] 
15 -ICINV [Icache (instruction cache) Invalidation 

Strobe] 

Invalidation of the cache is performed by a maximum of 
three clocks, and write from the 10 bus to memory does not 
end at three clocks. The cache invalidation unit 2005, 

20 therefore, does not perform handshake at the end of 

invalidation using the Stop_L signal output by the CPU shell 
401. To be prepared for further modifications, however, 
bSnoopWait is driven on the 10 bus at the same cycle as Stop__L . 
In a case where write from the 10 bus has occurred in 

25 the present implementation, Icache also is invalidated for 
safety's sake. If a self -modifying code is prohibited by 
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the operating system and invalidation of the instruction 
cache is performed intentionally at loading of data which 
may possibly be used as an instruction, then invalidation 
of Icache is not necessary. In such case some improvement 
5 in performance is desired. 
<Memory map> 

Figs. 23A - 23D and Figs. 24 A - 24D illustrate memory 
maps. Fig. 23A shows a virtual memory map, Fig. 23Baphysical 
memory map, Fig. 23C a memory map of G bus address space and 
10 Fig. 23D a memory map of 10 bus address space. Figs. 24A 
- 24D are maps showing 512 MB of the shaded portions in Figs. 
23A - 23D. 

The memory module of the processor core is based on the 
R3000. The physical address space of the processor core is 

15 four GB owing to 32 -bit addressing. Similarly, 3 2 -bit 

addressing is implemented for the virtual space. The maximum 
size of the user process is 2 GB. Address mapping in the 
kernel mode and address mapping in the user mode differ. The 
Figures show memory maps in a case where an MMP is not used. 

20 (User-mode virtual addressing) 

In virtual addressing in the user mode, 2 GB of user 
virtual address space (kuseg) becomes effective. Addresses 
of this user segment start from 0x00000000 and all effective 
access has an msb cleared to 0. In the user mode, reference 

25 to an address for which the msb has been set gives rise to 
exception treatment of address error. TLB maps all 
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references to kuseg similarly in the user mode and kernel 
mode. Cacheable kuseg usually is used to retain user codes 
and data. 

(Kernel -mode virtual addressing) 
5 Virtual address space in the kernel mode has four 

address segments. 

•kuseg: 2 GB from 0x00000000 of the virtual address. 
Caching and mapping in page units are possible . This segment 
is overlapped by kernel memory access and user memory access . 

10 -ksegO: 512 MB from 0x80000000 of the virtual address. 

Mapping is performed directly to the first 512 MB of the 
physical memory. Though reference is cached, the TLB is not 
used in address conversion. Ordinarily kesgO is used for 
kernel execution codes and kernel data. 

15 -ksegl: 512 MB from OxAOOOOOOO of the virtual address. 

Mapping is performed directly to the first 512 MB of the 
physical memory. Though reference is cached, the TLB is not 
used in address conversion. Ordinarily kesgl is used for 
the I/O register, ROM code or disk buffer, depending upon 

20 the operating system. 

•kseg2; 1 GB from OxCOOOOOOO of the virtual address. 
Mapping is from the virtual address to the physical address 
by TLB in the same manner as kuseg. Caching is performed 
freely. The operating system ordinarily uses kseg2 for data 

25 in every process requiring remapping by a stack or context 
switch. 
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[Virtual address memory map (Figs. 23A, 24A) 3 
The virtual address space is 4 GB and is accessible by 
all memories and I/Os in the system. SYSTEM MEMORY (1 GB) 
exists in kuseg, 
5 An internal RAM {16 MB) exists in ksegO. This is 

implemented in a case where it is desired to program the 
vector of exceptional treatment, and the exceptional vector 
base address is set to 0x80000000. This address is mapped 
to 0x0000000 of the physical address space. 
10 A ROM, an I/O and a register exist in ksegl. Included 

are a boot ROM (16 MB) , an SBB internal register and MC 
internal register (16 MB) , an 10 bus 1/01 (16 MB: primitive 
10 bus registers such as a G bus arbiter internal register, 
10 bus arbiter internal register and PMU internal register) , 
15 10 bus 1/02 (16 MB) , 10 bus MEM (16 MB) , Gbus MEM (32 MB) , 
FONT ROM (240 MB) , FOOT ROM or RAM (16 MB) . 

PCI I/O (512 MB) , PCI MEM (512 MB) are present in kseg2 . 
Since ksegO, ksegl are both mapped to the first 512 MB 
of the physical address space, the first 512 MB of ksegO, 
20 ksegl and kuseg all refer to the same physical address space. 
[Physical address memory map (Figs. 23B, 24B) ] 
The physical address space also is 4 MB, just as the 
virtual address space, and is accessible by all memories and 
I/Os of the system. 
25 What holds for the physical address memory map also 

holds for the physical address memory map in regard to PCI, 



- 61 - 



I/O, PCI MEM and SYSTEM MEMORY. 

Since ksegl, kseg2 are both mapped to the first 512 
MB of the physical address space, ROM, I/O and Reg exist in 
the space from 0x0000000. 
5 [G bus memory map (Figs. 23C, 24C) ] 

The G bus address space is 4 GB and is accessible only 
by SYSTEM MEMORY, Gbus MEM and FONT. 

[10 bus memory map (Figs. 23D, 24D) ] 

The 10 bus address space is 4 GB and is accessible only 
10 by PCI, I/O, PCI MEM, SYSTEM MEMORY, 10 Bus 1/02, 10 Bus MEM 
and FONT. 

Since the IO bus I/Ol is a primitive register, the space 
from OxlCOOOOOO to 0x20000000 is protected from the PCI; 
access from the PCI is not possible. 

15 < Address switch> 

The address switch 2003 is for sending an address signal 
from the bus serving as the master to the bus serving as the 
slave via SBB 402 in order to perform a data transfer among 
the P bus, G bus, 10 bus and MC bus. In the transfer via 

20 the SBB 402, the buses that can serve as the master are the 
P bus, G bus and IO bus, and the buses that can serve as the 
slave are the 10 bus andMC bus. Any of the P, G and 10 buses 
may serve as the master with respect to the MC bus, and only 
the P bus may serve as a master and send an address signal 

25 to the IO bus. 

Further, transfer between the P bus and IO bus and 
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transfer between the G bus and MC bus can be performed 
s imul taneous ly . 

Fig. 25 is a block diagram of the address switch 2003. 
The switch 2003b is changed over by the switch sequencer 2003a 
5 to switch the slave between the 10 bus and MC bus, and the 
switch 2003c is changed over by the switch sequencer 2003a 
to switch the master among the P bus, G bus and 10 bus. By 
virtue of this arrangement, any of the P, G and 10 buses may 
serve as the master with respect to the MC bus, and only the 
10 P bus can serve as the master with regard to the 10 bus. 
Further, transfer between the P bus and 10 bus and transfer 
between the G bus and MC bus can be performed simultaneously. 

<Data switch> 

The data switch changes over the flow of data within 
15 the SBB a data transfer is performed among the P bus, G bus, 
10 bus and MC bus . Data is sent from the master to the slave 
at the time of a write operation and from the slave to the 
master at the time of a read operation. 

Fig. 26 is a block diagram of the data switch 2004. In 
20 this arrangement, selectors A-l - A- 3 andB-1, B-2 are changed 
over as shown in Table 7 . Control can be performed in such 
a manner that write or read is carried out with any of the 
P, G and 10 buses serves as the master and the 10 bus or MC 
bus serving as the slave. 

25 
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5 TABLE 7 

Master Slave W/R Data Flow A-l A-2 A-3 B-l B-2 



PBus 


IOBus 


Write 


P -> 10 




b 












Read 


10 -> P 










b 




MCBus 


Write 


P — > MC 


b 






a 








Read 


MC — » P 




a 






a 


GBus 


MCBus 


Write 


G — > MC 






a 


b 








Read 


MC — » G 


a 










IOBus 


MCBus 


Write 


10 -» MC 






b 


b 








Read 


MC -> 10 




a 









15 <Arbitration> 

In changing over the switches, the switch sequencer 
2003a within the SBB 402 performs the following three types 
of arbitration among connection requests from outside the 
SBB: 

20 1. CPU 

2 . G bus bus master 

3 . 10 bus bus master 

The type of arbitration is decided by the present bus 
switch connection state and a prior set in advance. The 
25 result is a changeover in the address switch and data switch 
connections . 
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<Timing charts> 

Figs. 27 through 32 are timing charts, in which Fig. 

27 is a timing chart of write/read cycles from a G bus, Fig. 

28 a timing chart showing the burst stop cycle of a G bus, 
5 and Figs* 29 through 32 timing charts showing the transaction 

stop cycle of a G bus. 

2.6. PCI bus interface 

Fig. 33 is a block diagram of the PCI bus interface 416. 
The PCI bus interface 416 is a block for interfacing 
10 an 10 bus that is general -purpose 10 bus within the DoEngine 
and a PCI bus that is an 10 bus external to the chip. Depending 
upon the input pin settings, it is possible at the time of 
restart to switch between a host bridge arrangement in which 
a PCI bus configuration is capable of being issued and a 
15 target configuration in which the PCI bus configuration is 
not issued* 

The 10 bus interface has a master DMA controller 3301 
which, in a case where an access request for resources within 
the DoEngine has arrived from the PCI bus master via a PCI 

20 bus signal interface 3302, bridges this access request to 
the interior of the 10 bus as an 10 bus master. 

Furthermore, the master DMA controller 3301 is capable 
of performing a DMA transfer from the memory mapped on the 
PCI bus to the DoEngine memory. At this time the controller 

25 issues a transfer destination address (bPciAddr [31 : 0] and 
an ID signal (bPcilD) of the PCI master controller 3301 to 
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the 10 bus and arbitration sequencer at the same time as a 
bus request in order to perform operation while adhering to 
the access order of 10 bus DMA and G bus DMA intended by the 
programmer . 

5 The master DMA controller 3301 accepts a bus grant 

(bPciBGnt_L) and, when data transfer using the bus ends, 
terminates the assertion of the ID signal (bPcilD) . 

It should be noted that the PCI bus is in conformity 
with a 33-MHz, 32-bit PCI 2.1. 
10 2.7 G bus arbiter 

Fig. 34 is a block diagram of the G bus arbiter (GBA) 

406. 

The G bus arbitration is a central arbitration scheme 
and possesses a special-purpose request signal 
15 [g (mastername) Req_L] and a grant signal 

[g (mastername) Gnt_L] with regard to each bus master . In Fig . 
34, mastername is Ml - M4. The bus arbiter 406 supports up 
to four bus masters on the G bus and has the following 
features : 

20 -The arbiter can be programmed by setting a register 

3401a within the arbiter. The setting of the register is 

performed from the 10 bus. 

•There is a fair arbitration mode in which bus privilege 

is granted fairly with all bus masters having the same right 
25 of priority, and a high-priority arbitration mode which 

raises the right of priority of any one bus master and causes 
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the bus to be given priority in use. Which bus master is 
granted the right of priority is decided by the setting of 
the register 3401b. 

•It is possible to set the number of times a priority 
5 bus master can use a bus successively. 

•In regard to a transaction for which the address phase 
has already started but not the data phase, a transaction 
cycle for stopping this transaction is supported. 

•Programming of sequential processing in a plurality 
10 of bus masters can be performed (this will be described 
later) . The programmed sequence is stored in a register table 
3401a. 

•The arbiter has a mechanism in which, in a case where 
a G bus master and 10 bus master have issued a write 

15 successively to the same memory address, puts the granting 
of bus use permission on hold in regard to a specific master 
based upon a master ID signal and stop signal from a 
synchronizing unit, this mechanism being for the purpose of 
maintaining the access sequence intended by the programmer . 

20 It should be noted that programming of a register is 

carried out from the CPU 401 via the 10 bus. 
(Arbitration sequencer) 

Arbitration sequencers 3402a, 3402b, which are at the 
core of the G bus arbiter, perform G bus arbitration between 
25 one priority master and four other non-priority masters . The 
fair arbitration is realized by allocating request signals 
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and grant signals from four bus masters to the four non- 
priority masters by a request dispatch circuit 3403 and grant 
dispatch circuit 3404. Further, the high-priority 
arbitration mode is realized by allocating any one of the 
5 four bus masters to a priority master of the high-priority 
arbitration sequencer 3402a. These allocations are 
performed in accordance with the setting of registers 3401a, 
3401b. The priority bus master is capable of acquiring bus 
use privilege at a probability higher than that of the other 

10 masters in the high-priority arbitration mode. 

Furthermore, in addition to the fact that adjustment 
of bus acquisition probability by the priority bus master 
allocated to the high-priority sequencer 3402a is possible 
in the high-priority arbitration mode, the priority bus 

15 master can use the bus successively. The number of times 
the bus can be used in succession can be changed by a 
programmable register. This means that bus occupancy can 
be adjusted in such a manner that the bus is used often by 
a certain specific master. 

20 (Fair arbitration mode) 

In this mode all of the bus masters have the same 
priority and opportunities for granting bus privileges are 
equal . When a bus is free , the bus master that issues a request 
first can obtain the bus privilege. In a case where a 

25 plurality of bus masters issue requests simultaneously, bus 
privilege is granted sequentially in accordance with a 
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predetermined order (this is a round-robin scheme) . For 
example, if all bus masters from Ml to M4 have issued requests 
at the same clock, bus privilege is granted in the order Ml 
— > M2 — > M3 — » M4 . In a case where all bus masters issue requests 

5 again at the end of the transaction of M4, bus privilege is 
granted through a similar sequence, i.e., Ml — > M2 — » M3 — » 
M4 — » Ml — > M2 • • • . If some bus masters have issued requests, 
privilege is granted to the master having a large number 
closest to the master that used the bus last, with a round 

10 wrap being performed from M4 to Ml. 

Once bus privilege has shifted to another bus master, 
the bus privilege cannot be obtained again unless it is after 
the granting of bus privilege to all other bus masters that 
have issued requests. 

15 {High-priority arbitration) 

In this mode one bus master (a bus master that has been 
registered in the register 3401b) becomes a priority bus 
master having a right of priority higher than that of other 
bus masters. The bus privilege is granted with a priority 

20 higher than that of the other bus masters. The orders of 
priority of bus masters other than the priority bus master 
are all the same. 

In a case where a plurality of path masters issue 
requests and the priority bus master issues requests 

25 successively, the priority bus master and the other non- 
priority bus masters obtain the bus privilege by turns. 
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Once bus privilege has shifted from a non-priority bus 
master to another bus master, the non -priority bus master 
cannot obtain the bus privilege again unless it is after the 
granting of bus privilege to all other bus masters that have 
5 issued requests. 

(Transaction stop cycle) 

When the priority bus master issues a request in the 
high-priority arbitration mode, a transaction being carried 
out can be stopped and the priority bus master can obtain 

10 the bus privilege if the data phase has not yet been started, 
even if the other bus masters have already started the address 
phase. However, if the priority bus master possessed the 
bus privilege immediately before, the limitation on the 
number of times the bus privilege can be obtained 

15 successively by the priority bus master cannot be exceeded. 

If the suspended bus master is issuing a request when 
the transaction of the priority bus master ends, then it is 
given priority in the granting of the bus privilege. 
(Changeover of priority bus master) 

20 It will suffice to rewrite the register 3401b in order 

to change over the priority bus master. When the register 
for selecting the priority bus master is rewritten, the 
priority bus master is rewritten upon waiting for the end 
of the transaction being executed at this time. The arbiter 

25 returns to the idle state and arbitration is performed anew 
on the grounds that the bus master that was issuing the 
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request at such time issued the request simultaneously. 

Sufficient care must be taken in changing over the 
priority bus master. If the priority bus master is changed 
over to a different bus master before DMA of the bus master 
5 to be given priority ends, the degree of priority of the DMA 
of the initial priority bus master will decline. If it is 
not desired to lower the degree of priority of the initial 
priority bus master, then it is necessary to perform the 
changeover of the priority bus master after it is confirmed 

10 that DMA has ended. 

With software that requires that the changeover of the 
priority bus master be performed dynamically not only at 
system booting but also during system operation, the 
changeover of the priority bus master should be performed 

15 by suspending the setting of all bus masters and DMA control 
in such a manner that a new DMA request will not be generated 
on the G bus, subsequently setting an appropriate value in 
the register within the G bus arbiter 406, checking the status 
register in the G bus arbiter and activating access and DMA 

20 anew on the G bus upon confirming that the right of priority 
of the bus master has been changed over. 

There is a possibility that the dynamic changeover of 
the priority bus master will change or violate the real- 
time assurance of the operating system and the setting of 

25 task priority. This means that the changeover must be 
performed upon giving full consideration to the above. 
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(Sequential processing) 

Fig. 35 is a block diagram relating to DMA by bus masters 
on a G bus, with the focus being on the G bus 404 in a DoEngine 
400. 

5 Consider a series of processing operations in a case 

where a plurality of bus masters execute processing 
sequentially, e.g. , in which after processing A is executed 
by a bus master 1 with respect to data in a memory 3501, 
processing B is executed by bus master 2 and then the 

10 processed data is sent to bus master 4. 

The order in which buses are used by bus masters, the 
conditions for starting granting of bus privilege and the 
conditions for ending the granting of bus privilege are set 
in a register table 3401a within the bus arbiter 406 via the 

15 10 bus 405 by the software that performs this processing, 
i.e. , by the program executed by CPU 401. In this example, 
the settings are as follows: 

Bus Master Starting Conditions Ending Conditions 
1. Bus Master 1: gM2Buf Empty gMlBuf Ready 

20 2. Bus Master 2: gMlBuf Ready gMlBuf Empty 

3. Bus Master 4: gM2Buf Ready gM2Buf Empty 

More specifically, upon receiving a signal set as a starting 
condition from each bus master, the G bus arbiter 406 grants 
bus use privilege to each bus master. Upon receiving a signal 

25 set as an ending condition, the G bus arbiter 406 deprives 
the bus master of the bus use privilege. 
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The software sets DMA for each bus master. As a result, 
each master issues a request [g(mastername)Req_L] to the G 
bus arbiter 404. The G-but arbiter 404 grants bus privilege 
(gMlGnt_L) to bus master 1 in accordance with the sequence 
5 that has been registered in the register table 3401a. The 
bus master 1 reads data is certain units from the memory 301, 
executes the processing A and writes the data to a buffer 
within the bus master 1. The bus master 1 finishes the 
processing of one unit and notifies the arbiter 406 , by way 

10 of the signal gMlBuf Ready, of the fact that the buffer has 
been prepared. 

Upon receiving this notification, the arbiter 406 takes 
the bus privilege from bus master 1 and grants it to bus master 
2 in accordance with the conditions, registered in the 

15 register table 3401a, under which a bus master grants and 
removes bus privilege. The bus master 2 reads the data from 
the buffer of bus master 1, executes the processing B and 
stores the data in a buffer within the bus master 2. If the 
buffer in bus master 1 becomes empty during this time, 

20 gMlBuf Empty is asserted and the arbiter 406 terminates the 
granting of bus privilege to bus master 2. Bus master 2 
executes processing B and, when buffer preparation is 
complete, gives notification of this by the signal 
gM2Buf Ready. 

25 Upon receiving this notification, the arbiter 406 now 

grants bus privilege to bus master 4 in accordance with the 
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content of register 3401a. The bus master 4 reads the data 
from the buffer of bus master 2 . If the buffer in bus master 
2 becomes empty, the arbiter 406 is so notified by 
gM2BufEmpty. Upon receiving this notification, the arbiter 
5 406 again grants bus 

privilege to bus master 1 in accordance with the content of 
register 3401a and starts processing of the next data. 

If all DMAs set in the respective bus masters have ended, 
the respective bus masters notify the processor by an 

10 interrupt. When end notifications from all bus masters have 
been obtained, the software recognizes that the series of 
processing operations has ended. 

The above-described operation is that of the complete 
sequential mode. A bus master other than one dealing with 

15 sequential processing cannot use a bus. A priority 

sequential mode is available in order to make it possible 
for a bus master not associated with sequential processing 
to use a bus even during sequential processing. Changeover 
between these modes is carried out by programming the 

20 register in the arbiter 406 . In the priority sequential mode, 
a bus master that executes sequential processing can use the 
bus preferentially but if a bus master is one having nothing 
to do with sequential processing, use of the bus is allowed. 
Arbitration between a bus master that performs sequential 

25 processing and a bus master unrelated to sequential 

processing is equivalent to that in the high-priority 
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arbitration mode described above. Of course, bus privilege 
is not granted to a bus master, associated with sequential 
processing, whose own turn has not come because the 
conditions for granting bus privilege have not been 
5 satisfied. 

(Mechanism for maintaining access sequence) 
If the signal stopSpc has been asserted, the scanner 
printer controller 408, which is one of the G bus masters, 
is excluded from arbitration and the bus use privilege is 

10 not granted even if a request is asserted. Arbitration is 
carried out among masters from which this master has been 
excluded. A detailed description is given in the section 
on the 10 bus arbiter. 
<Timing diagrams> 

15 Figs. 36 - 39 are useful in describing the timing of 

G bus arbitration. Fig. 36 shows an example of a fair 
arbitration mode (fair mode) in a case where the number of 
times a bus is used in succession has been set to one in regard 
to all bus masters 1-4. A second bus request (issued from 

20 timing 4) from bus master 1 waits for all other bus masters 
issuing bus requests to be dealt with one time each. 

Fig. 37 shows an example of a fair arbitration mode in 
a case where the number of times a bus is used in succession 
is set to two in regard to bus master 1 and to one in regard 

25 to other bus masters. A second bus request (issued from 
timing 4) from bus master 1 is allowed immediately after the 
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first request. The other bus masters wait until this 
processing is finished. 

Fig. 38 shows an example of a high-priority arbitration 
mode in a case where the number of times a bus is used in 
5 succession is one each, with bus master 1 being set as a 
high-priority bus. In order for the bus use privilege to 
be allowed alternately for the priority bus master and 
non-priority bus masters, the second bus request from bus 
master 1 is allowed after use of the bus by bus master 2 and 

10 the bus request from bus master 4 is allowed after second 
use of the bus by bus master 1. The second bus request from 
bus master 2 is allowed after the end of bus use by all other 
bus masters issuing bus requests, namely bus master 1 and 
bus master 4 in Fig. 38. 

15 Fig. 39 shows an example in which, despite the fact that 

a bus request from bus master 4 has been allowed, the request 
is canceled by a bus request from bus master 1. When bus 
use by bus master 1 ends in this case, the bus request from 
bus master 4 is given preference over the bus request from 

20 bus master 2. 

2.8. 10 bus arbiter 

Fig. 40 is a block diagram of the 10 bus arbiter 407. 
The IO arbiter 407 accepts a bus use request from the 
10 bus 405, which is an 10 general -purpose bus within the 
25 DoEngine, performs arbitration, grants permission to use the 
bus to one selected master and forbids two or more masters 
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from performing bus access simultaneously. 

The arbitration scheme is arranged to have three levels 
of priority and programmably allocates a plurality of masters 
to each of these priorities. The allocation is such that 
5 a maximum of three masters are allocated to the highest level 
of priority, seven masters to the intermediate level of 
priority and three masters to the lowest level of priority. 
The arbiter has a mechanism in which, in a case where 
a G bus master and 10 bus master have issued a write 

10 successively to the same memory address, puts the granting 
of bus use permission on hold in regard to a specific master 
based upon a master ID signal and stop signal from a 
synchronizing unit, this mechanism being for the purpose of 
maintaining the access sequence intended by the programmer. 

15 (Arbitration sequencer) 

The 10 bus arbiter is composed of three arbitration 
sequencers 4002, 4003 and 4004. The sequencers 4002, 4003, 
4004 are internally provided with three, seven and three bus 
master arbitration sequencers, respectively, having the 

20 high, intermediate and low priority levels, respectively. 
Request signals from all units for which there is a 
possibility of becoming bus masters on the 10 bus as well 
as grant signals to these units are distributed to the three 
sequence units by a request selector and grant selector. In 

25 regard to the distribution, a unique combination can be 
selected from a plurality of combinations by a software 
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programmable register 4005a within the BBus interface 4005. 

For example, fair arbitration is realized among the 
seven masters by connecting a maximum of seven master 
requests to the arbitration sequence 4003 of the intermediate 
5 priority level. By allocating several of the bus masters 
to the arbitration sequence 4002 of the high priority level, 
these masters can the bus use privilege at a probability 
higher than of the other masters . Furthermore, by connecting 
several requests to the sequencer 4004 of the low priority, 

10 the ratio of bus use can be kept low. Further, in addition 
to adjusting the probability of bus acquisition, a master 
that has been allocated to the high-priority sequencer 4002 
can use the bus successively. The number of times the bus 
can be used successively can be varied by the programmable 

15 register 4005a. This means that bus occupancy can be adjusted 
so that a bus can be used often by a certain specific master. 
(Fair bus arbitration scheme) 

A method of implementing fair arbitration will be 
described taking the intermediate-priority sequencer 4003 

20 as an example. All bus masters connected to one sequencer 
have the same priority and the opportunities to be granted 
bus privilege are equal. When a bus is free, the bus master 
that issues a request first can obtain the bus privilege 
(first-come first-serve) . In a case where a plurality of 

25 bus masters issue requests simultaneously, bus privilege is 
granted sequentially in accordance with a predetermined 
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order (this is a round-robin scheme) . For example, if all 
bus masters from Ml to M7 have issued requests at the same 
clock, bus privilege is granted in the order Ml — > M2 — > M3 
-» M4 — > M5 — > M6 — > M7 . In a case where all bus masters issue 
5 requests again at the end of the transaction of M7, bus 
privilege is granted through a similar sequence, i.e., Ml 
-> M2 -> M3 -» M4 -4 M5 -» M6 -4 M7 -4 Ml -> M2 • • • . If some 

bus masters have issued requests, privilege is granted to 
the master whose number is larger than and closest to the 
10 master that used the bus last, with a round wrap being 
performed from M7 to Ml. 

(High-priority arbitration) 

The 10 bus interface is composed of three arbitration 
sequencers of high, intermediate and low priority levels. 
15 Arbitration provided with a degree of priority can be 

realized by allocating a plurality of bus requests to high- 
and low-priority arbiters selectively. 

For example, by allocating one master to a high priority 
and the remaining masters to intermediate priority, the one 
20 master will become a priority bus master having a right of 
priority higher than that of the other bus masters and will 
be granted bus privilege preferentially in comparison with 
other bus masters. The priorities of bus masters that have 
been allocated to arbitration sequencers having the same 
25 right of priority are the same. 

In a case where a plurality of bus masters issue requests 
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and the priority bus master issues requests successively, 
the priority bus master and the other non-priority bus 
masters obtain the bus privilege by turns. In a case where 
M3 is the priority master and Ml, M2, M3, M4 keep on issuing 
5 requests, bus use privilege is granted in the order M3 — > 
Ml -» M3 H> M2 -> M3 -> M4 H> M3 -> Ml. 

Further, the high-priority bus master is capable of 
acquiring the bus privilege successively a number of times 
set beforehand in a programmable register within the arbiter . 

10 The bus can be used successively a maximum of four times. 
When bus privilege shifts to another bus master from 
a bus master other than the priority bus master, this bus 
master cannot obtain the bus privilege again unless it is 
after the granting of bus privilege to all other bus masters 

15 that have issued requests. In a case where one bus master 
issues a request successively, it is capable of obtaining 
bus privilege successively if there are no other bus masters 
issuing requests . If another bus master is issuing a request, 
then this bus master can obtain the bus privilege 

20 successively a number of times set in advance. Once bus 
privilege has shifted to another bus master, the bus 
privilege cannot be obtained again unless it is after the 
granting of bus privilege to all other bus masters that have 
issued requests . 

25 A maximum of three requests can be allocated to the 

low-priority arbitration sequencer 4004. The bus use 
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privilege will not be granted to a master that has been 
allocated to the low-priority sequencer 4004 unless there 
are no longer requests from all masters allocated to the 
intermediate- and high-priority sequencers . The allocation 
5 of a bus master to this sequencer must be carried out with 
sufficient care. 

(Changeover of priority bus master) 

It will suffice to rewrite the register in the arbiter 
in order to change over the priority bus master. When the 

10 register for selecting the priority bus master is rewritten, 
the priority bus master is rewritten upon waiting for the 
end of the transaction being executed at this time. The 
arbiter returns to the idle state and arbitration is 
performed anew on the grounds that the bus master that was 

15 issuing the request at such time issued the request 
s imu 1 taneou s ly . 

Sufficient care must be taken in making the changeover. 
If the priority bus master is changed over to a different 
bus master before DMA of the bus master to be given priority 

20 ends, the degree of priority of the DMA of the initial 

priority bus master will decline. If it is not desired to 
lower the degree of priority of the initial priority bus 
master, then it is necessary to perform the changeover of 
the priority bus master after it is confirmed that DMA has 

25 ended. 

With software that requires that the changeover of the 
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priority bus master be performed dynamically not only at 
system booting but also during system operation, the 
changeover of the priority bus master should be performed 
by suspending the setting of all bus masters and DMA control 
5 in such a manner that a new DMA request will not be generated 
on the 10 bus, subsequently setting an appropriate value in 
the register within the 10 bus arbiter 407, checking the 
status register in the 10 bus arbiter and activating access 
and DMA anew on the 10 bus upon conf irming that the right 

10 of priority of the bus master has been changed over. 

There is a possibility that the dynamic changeover of 
the priority bus master will change or violate the real- 
time assurance of the operating system and the setting of 
task priority. This means that the changeover must be 

15 performed upon giving full consideration to the above. 
(Access sequence control mechanism) 
The 10 bus arbiter 407 includes an access sequence 
control mechanism. The access sequence control mechanism 
is implemented by the synchronizing unit 4001 and bus-use 

20 privilege issuance suppression mechanisms incorporated in 
the 10 bus arbiter 407 and G bus arbiter 406. The bus-use 
privilege issuance suppression mechanism incorporated in the 
10 bus arbiter 407 operates in the same manner as that of 
the Gbus arbiter. That is, if a stopPci signal has entered, 

25 a bus request is issued by the Pci bus master. Even if the 
state is such that it is possible for the bus use privilege 
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to be granted to this bus master as a result of arbitration, 
the bus use privilege is not issued and is granted to another 
master. More specifically, if the stopPci signal has 
entered, the above is carried out by immediately masking 
5 bPciReq_L. 

Operation is exactly the same also in the case of a bus 
request from the LAN controller 414 and a stop signal. Fig. 
41 is a block diagram of the synchronizing unit 4001. 
Comparator units 4101 - 4103 are connected within the 

10 synchronizing unit in relation to all combinations among a 
plurality of DMA masters. In regard to a DMA master on the 
G bus in a DoEngine, only the scanner /printer controller 408 
exists . Two units, namely a DMAPCI unit and LAN unit, exists 
on the 10 bus . The 10 bus interface within the SBB is a bus 

15 master on the 10 bus. However, since it does not directly 
access the memory, an ID and transfer destination address 
are not sent to the synchronizing unit 4001. 

Fig. 42 illustrates one comparator unit (comparator 
unit 1) in the synchronizing unit . The other comparator units 

20 are identically constructed. 

A DMA block belonging to the PCI interface 416 or the 
scanner /printer control 1 er 408 notifies the synchronizing 
unit 4001 of the address of a transfer destination and a 
request signal specific to this DMA block at the moment DMA 

25 write is programmed. 

Each comparator unit stores the address of the 
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destination together with the present time from an internal 
timer at the moment a request is output by each DMA block. 
At the moment an address and a request relating to DMA write 
enter from another DMA block, the comparator unit compares 
5 both addresses. If the two addresses match, the times stored 
in the respective registers are compared. Permission to the 
master to use the bus is not granted in regard to the bus 
arbiter of a bus to which has been connected the .DMA block 
that issued the DMA write request later in terms of time. 

10 This is communicated to the bus arbiter of each bus by a 
stop (ID) signal. 

No bus arbiter allocates bus use privilege by 
arbitration to a master notified by the stop (ID) signal. 
As time passes and the DMA write to the pertinent memory 

15 address is ended by the bus master that issued the access 
request first, this master abandons the request with respect 
to the synchronizing unit. With respect to the bus arbiter 
of the bus connected to the DMA block that issued the DMA 
write request second, the synchronizing unit sends this DMA 

20 block a signal inhibiting bus use. DMA write of the master 
that is to execute the DMA write is carried out subsequently. 

When both DMA writes end and both requests are 
abandoned, the timer is reset. The counting up of the timer 
is carried out again at the moment a request is issued again 

25 from either of the masters. 

2.9. Scanner/printer controller 
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Fig. 43 is a block diagram of the scanner /printer 
controller 408. 

As shown in Fig. 43, the scanner/printer controller 408 
is connected to a scanner and printer by video I/Fs and 
5 interfaces an internal G bus and 10 bus. The controller 408 
may be broken down broadly into the following eight blocks : 

1. Scanner control unit 4304 ... This controls the 
operation of the scanner via a video I/F. 

2. Printer control unit 4304 ... This controls the 
10 operation of the printer via a video I/F. 

3. Scanner image processing unit 4305 . . . This applies 
image processing to image data that enters from the scanner. 

4. Printer image processing unit 4308 . . . This applies 
image processing to image data that is output to the printer. 

15 5. Scanner /video synchronizing unit 4306 ... This 

generates input synchronizing timing with regard to image 
data that enters from the scanner. 

6. Printer /video synchronizing unit 4307 ... This 
generates output timing with regard to image data that is 

20 output to the printer. In a case of a combination in which 
the printer and scanner are capable of being synchronized, 
this unit generates video timing for a copying operation 
together with the scanner /video synchronizing unit 4306. 

7. Data transfer control unit 4302 ... This controls 
25 the data transfer operation. In the case of the DMA 

operation, it supports both master and slave operation. 
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8. G bus / 10 bus interface unit 43 01 ... This is an 
interface unit for connecting the G bus and 10 bus to the 
scanner /printer controller. The connection to the data 
transfer control unit 4302 is by an L bus. 
5 < Scanner /video synchronizing control unit 4306> 

Fig. 44 is a block diagram of the scanner /video 
synchronization control unit 4306. 

(Overview of scanner /video synchronizing control 

unit) 

10 The scanner /video synchronizing control unit 4306 

generates an image-data capture timing signal, an image 
processing timing signal and a timing signal for writing to 
a FIFO, which is a transfer buffer, based upon a vertical 
synchronizing signal (SVSYNC) , a horizontal synchronizing 

15 signal (SHSYNC) and an image data synchronizing clock (SVCLK) 
of image data entered from the scanner. 

The unit manages delay of the image data and number of 
pixels captured in the main-scan direction, as well as delay 
and number of lines captured in the sub-scan direction. The 

20 unit generates a status signal (SALLEND) at the timing at 
which capture of a set amount of image data ends. A line 
counter 4401 manages delay in the sub-scan direction and 
captured line count and generates a vertical synchronizing 
signal (SEFHSYNC) regarding an effective area of the read 

25 image. A pixel counter 4402 manages image capture delay and 
captured pixel count in the main-scan direction. The counter 
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4402 generates a write timing signal (SCFWR) for storing 
captured image data in the FIFO. A page counter 4403 manages 
entered image data in the page units . When input of a set 
number of pages of image data ends, the counter 4403 generates 
5 an end signal (SALLPEND) . 

The values set in the line counter 4401, pixel counter 
4402 and page counter 4403 are read and written by a control 
register 4310, Signals other than those mentioned are above 
are as follows : 
10 -write data 

♦read data 

•line counter write signal 

•line counter read signal 

•pixel counter write signal 
15 * pixel counter read signal 

•page counter write signal 

•page counter read signal 

<Pr inter /video synchronizing control unit 4307> 

Fig. 45 is a block diagram of the printer /video 
20 synchronization control unit 4307. 

(Overview of printer /video synchronizing control 

unit) 

The printer /video synchronizing control unit 4307 
generates an image-data capture timing signal, an image 
25 processing timing signal and a timing signal (PRFRD) for 
reading from a FIFO, which is a transfer buffer, based upon 



IFWDATA[31:0] 

IFRDATA[31:0] 

SLCSET 

SLCRD 

SPCSET 

SPCRD 

SPAGESET 

SPAGERD 
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a vertical synchronizing signal (PVSYNC) , a horizontal 
synchronizing signal (PHSYNC) and an image data 
synchronizing clock (PVCLK) of image data entered from the 
printer* 

5 The unit manages delay of the image data and number of 

pixels captured in the main-scan direction, as well as delay 
and number of lines captured in the sub-scan direction. The 
unit generates a status signal (PLEND) at the timing at which 
capture of a set amount of image data ends. A line counter 

10 4501 manages delay in the sub-scan direction and output line 
count and generates a vertical synchronizing signal 
(PEFHSYNC) regarding an effective area of the image to be 
output. A pixel counter 4502 manages image output delay and 
output pixel count in the main-scan direction. The counter 

15 4502 generates a read timing signal (PRFRD) for reading 
output image data out of the FIFO. A page counter 4503 manages 
image data to be output in page units. When output of a set 
number of pages of image data ends , the counter 4503 generates 
an end signal (PALLPEND) . 

20 The values set in the line counter 4501, pixel counter 

4502 and page counter 4503 are read and written by the control 
register 4310. Signals other than those mentioned are above 
are as follows: 

•write data : IFWDATA[31 : 0] 

25 -read data : IFRDATA [31:0] 

•line counter write signal : PLCSET 
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•line counter read signal : PLCRD 

•pixel counter write signal : PPCSET 
•pixel counter read signal : PPCRD 

•page counter write signal : PPAGESET 

5 -page counter read signal : PPAGERD 

<Scanner FIFO controller 4311> 

Fig. 46 is a block diagram of a scanner FIFO controller. 
A scanner FIFO controller 4311 (see Fig. 43) includes FIFOs 
as buffers for transferring, via the G bus or 10 bus, image 

10 data that has entered from the scanner, and a circuit for 
controlling these FIFOs. The controller has two FIFOs 4602, 
4603 each having a capacity of 1024 bits and a data width 
of 24 bytes {eight bits for each of R, G and B) . These FIFOs 
operate as a double buffer for alternately performing a G 

15 bus / 10 bus data transfer operation and an operation for 
inputting image data from the scanner. FIFO data 
input/output is controlled by a scanner FIFO selector 4601 
using a FIFO full flag (FF) and empty flag (EF) . 
<Printer FIFO controller 4312> 

20 Fig. 47 is a block diagram of the printer FIFO controller 

4312 (see Fig. 43) . The printer FIFO controller 4311 includes 
FIFOs as buffers for transferring, via the G bus or 10 bus, 
image data that is output to the printer, and a circuit for 
controlling these FIFOs. The controller 4312 has two FIFOs 

25 4702, 4703 each having a capacity of 1024 bytes and a data 
width of 24 bits (eight bits for each of R, G and B) . These 
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FIFOs operate as a double buffer for alternately performing 
a G bus / 10 bus data transfer operation and an operation 
for outputting image data to the printer. FIFO data 
input/output is controlled by a printer FIFO selector 4701 
5 using a FIFO full flag (FF) and empty flag (EF) . 

The scanner printer controller 408 has data paths for 
outputting scanner data directly to the printer, as shown 
in Fig. 43, in order that the scanner and printer may be 
operated synchronously to perform a copying operation . These 
10 data paths are selectable depending upon the synchronization 
of the data inputs and outputs of the scanner and printer. 
<Data transfer control unit 4302> 

Fig. 48 is a block diagram of the data transfer control 
unit 4302. The data transfer control unit 4302 is a block 
15 for controlling the input and output of data to and from the 
L bus and includes a chain controller 4801, a master DMA 
controller 4802 and a transfer arbiter 4803, etc. 

The data transfer control unit controls the following 
operations as a master: 
20 1. image data DMA transfer from the scanner and 

reference to a chain table; and 

2 . image data DMA transfer to the printer and reference 
to a chain table; and 

controls the following operations as a slave: 
25 1. write/read of internal registers; 

2. image data transfer from the scanner; and 



- 90 - 



3. image data transfer to the printer. 
(Chain controller) 

Fig. 49 is a block diagram of the chain controller 4801. 
The chain controller comprises an address pointer block 
5 indicating a chain table and an address pointer block 
indicating the transfer destination of DMA. This is a 
transfer destination address generating block for when the 
scanner /printer controller performs DMA acting as a master 
and supports chain DMA. Scanner data transfer and printer 
10 data transfer are performed independently. 
<L bus> 

This is a local bus in the scanner/printer controller 
connecting the Gbus / 10 bus interface unit and data transfer 
unit. It includes the signals indicated below. In regard 

15 to signal input and output, a signal output from the data 
transfer control unit 43 02 to the G bus / 10 interface unit 
4301 is represented by OUT, and a signal input to the data 
transfer control unit 4302 from the G bus / 10 bus interface 
unit 4301 is represented by IN. 

20 • IFCLK (IN) — * This is the basic clock of the L bus. 

•IFRDATA[63:0] (OUT) • - * This is a 64-bit data bus for 
an output from the data transfer control unit to the G bus 
/ 10 bus interface unit. The data transfer control unit is 
used in both master and slave operations. 

25 -IFWDATA[63:0] (IN) This is a 64-bit data bus for 

an output from the G bus / 10 bus interface unit to the data 
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transfer control unit. The data transfer control unit is 
used in both master and slave operations . 

♦ IFMDTREQ (OUT) • • • With the data transfer control unit 
acting as a master, this indicates the effective status of 

5 a data transfer request, data and address. When "high" the 
signal indicates the effective 

status of the data transfer request and address bus 
IFMAD[3:12] . 

•IFMAD[31:2] (OUT) This is an address bus which 

10 indicates the target address when the data transfer control 
unit operates as a master. The effective address is output 
when the IFMDTREQ signal is in the active state "high" . 

• IFMRW (OUT) This signal indicates data 

input/output when the data transfer control unit operates 
15 as a master. When this signal is "high", the data transfer 
control unit inputs data from IFWDATA[63 : 0] . When the signal 
is "low", the 

data transfer control unit outputs data to IFRDATA [63:0] . 

• IFMDTACK (IN) • • • This is a response signal to IFMDTREQ 
20 which is output from the G bus/ 10 bus interface unit when 

the data transfer control unit operates as a master. When 
this signal is "high", it indicates that IFRDATA [63:0] or 
IFWDATA [63:0] is the effective data. 

•PRIOR[3:0] (OUT) - This indicates the degree of 
25 priority of the data transfer when the data transfer control 
unit operates as a master. The degree of priority is as 
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defined in Table 8. 



5 TABLE 8 



PRI0R3 


PRI0R2 


PRIORI 


PRIORO 


PRIORITY 


1 


1 


1 


1 


HIGH 


1 


1 


1 


0 


t 






0 


0 


0 


1 


i 


0 


0 


0 


0 


LOW 



•MTSIZE[2:0] (OUT) • • • This indicates the unit size of 
a transfer when the data transfer control unit operates as 
10 a master. During a transfer of this unit size, IFMDTREQ 
remains active "high". Size is as indicated in Table 8. 



TABLE 9 



MSIZE2 


MSIZE1 


MSIZEO 


TRANSFER UNIT SIZE 


1 


1 


1 


64 bits X 64 


1 


1 


0 


64 bits X 48 


1 


0 


1 


64 bits X 32 


1 


0 


0 


64 bits X 16 


0 


1 


1 


64 bits X 4 


0 


1 


0 


64 bits X 2 


0 


0 


1 


64 bits 
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0 


0 


0 


32 bits 



This indicates the effective status of a data transfer 
request, data and address from the G bus / 10 bus interface 
unit when the data transfer control unit operates as a slave. 
5 When "high" the signal indicates the effective status of the 
data transfer request and address bus IFSAD[6:2] . 

•IFSAD[6:2] (IN) This is an address bus which 

indicates the target address when the data transfer control 
unit operates as a slave. The effective address is output 
10 when the IFSDTREQ signal is in the active state "high" . 

•IFSRW (IN) • • • This signal indicates data input /output 
when the data transfer control unit operates as a slave. When 
this signal is "high" , the data transfer control unit outputs 
data to IFRDATA [63:0] . When the signal is "low", the data 
15 transfer control unit inputs data from IFWDATA[63 : 0] . 

•IFMDTACK (OUT) This is a response signal to 

IFSDTREQ which is output from the G bus/ 10 bus interface 
unit when the data transfer control unit operates as a slave . 
When this signal is "high", it indicates that IFRDATA [63:0] 
20 or IFWDATA [63:0] is the effective data. 

•STSIZE (IN) • • • This indicates the data width from the 
G bus / 10 bus interface unit when the data transfer control 
unit operates as a slave. When this signal is "high", 
IFRDATA[63:0] or IFWDATA [ 63 : 0] becomes effective . When this 
25 signal is "low", IFRDATA [31:0] or IFWDATA[31 : 0] becomes 
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effective. 

<G bus / 10 bus interface unit> 

Fig. 50 is a block diagram of the G bus / 10 bus interface 
unit 4301. The G bus / 10 bus interface unit is the interface 
5 between the internal bus (L bus) and external bus (G bus / 
10 bus) of the copy engine. Though this unit is implemented 
in such a manner that it can be used by other function blocks, 
in this embodiment the copy engine makes use of the unit. 
It should be noted that the copy engine is a generic term 

10 which includes the scanner /printer controller 408 and the 
scanner and printer controlled by it. 

The G bus / 10 bus interface unit generally comprises 
three sections, namely a bus selector unit 5001, an 10 bus 
controller 5002 and a G bus controller 5003. 

15 When the copy engine operates as a DMA master, the bus 

selector unit 5001 performs a bus selection dynamically based 
upon the amount of burst transfer possible on the L bus, the 
degree of priority (degree of urgency) of the transfer, the 
transfer destination address and bus (G bus and 10 bus) idle 

20 information, and connects the L bus to the corresponding 
controller (G bus controller 5003 or 10 bus controller 5002) 
upon applying some preprocessing. When the copy engine 
operates as a DMA slave, the engine arbitrates requests from 
each of the buses (G bus and 10 bus) and connects the L bus 

25 to the bus having the highest priority. 

The G bus controller 5003 and 10 bus controller 5002 
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connect the bus (the G bus or 10 bus) to the L bus. Each 
of the units will be described below. 

The copy engine is a DMA master capable of DMA transfer 
with respect to both the G bus and 10 bus, and the G bus / 
5 10 bus interface unit 4301 decides the bus to be used when 
the DMA transfer is made. With the conventional system, the 
bus is changed over in dependence upon the transfer 
destination (address). However, good performance cannot be 
obtained from the overall system unless the transfer speed 

10 and ratio of use of each bus are taken into consideration. 

The bus selector unit 5001 performs efficient bus 
selection dynamically based upon the amount of burst transfer 
possible on the L bus, the degree of priority (degree of 
urgency) of the transfer, the transfer destination address 

15 and bus (G bus and 10 bus) idle information, and connects 
the L bus to the corresponding controller (G bus controller 
5003 or 10 bus controller 5002) upon applying some 
preprocessing. 

The G bus controller 5003 and 10 bus controller 5002 

20 send the write address and the ID of the function block (here 
the copy engine) to the bus (G bus or 10 bus) synchronizing 
unit that corresponds to the L bus. Each of these units will 
be described below. 

(Bus selector unit) 

25 Fig. 51 is a block diagram of the bus selector unit 5001. 

The operation of this unit will now be described. 
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[Operation when copy engine is master] 
In a case where the copy engine is a master, the engine 
is controlled by an L bus master sequencer 5101 of the bus 
selector unit. The L bus master sequencer 5101 becomes aware 
5 of a request for master operation from the copy engine by 
receiving IFMDTREQ (a master data request signal) from the 
copy engine. 

The copy engine outputs IFMAD[31:2] (master transfer 
address signal) , MTSIZE [2:0] (master transfer length signal) 

10 and IFMRW (master read/write signal) to the bus selector unit 
5001 at the same time that IFMDTREQ is asserted. The transfer 
address is latched in an address counter 5102 and the transfer 
length is latched in a length counter 5103. 

The L bus master sequencer 5101 decides whether to use 

15 the G bus or the 10 bus based upon the address counter, length 
counter, priority and busy states of the buses when transfer 
on the external bus is started. If the five lower order bits 
of the address counter are all "C's, or if the length counter 
is less than 64 bits x 4, then transfer on the G bus is 

20 impossible. The 10 bus, therefore, is selected. Otherwise 
the G bus is selected except for a case where priority is 
high, the G bus is currently in use and the 10 bus is idle. 
When transfer cycle for transfer to the external bus ends, 
the address counter 5102 and length counter 5103 are updated. 

25 If the content of the length counter is not zero, the 

above-described operation is repeated. The bus selection 
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standard is shown in Table 10. 



5 TABLE 10 



ADDRESS COUNTER [4:0] =0 
& 

LENGTH COUNTER > 
64 BITS X 4 


PRIORITY 


BUS STATUS 


BUS SELECTED 


10 BUS 


G BUS 


NO 








IO BUS 


YES 


LOW 






G BUS 


HIGH 


READY 


READY 


G BUS 


READY 


BUSY 


10 BUS 


BUSY 


READY 


G BUS 


BUSY 


BUSY 


G BUS 



In a transfer from the copy engine to the external bus, 
the L bus master sequencer 5101 asserts the IFMDTACK signal, 

10 requests the copy engine for data transfer and writes the 
obtained data to a data FIFO 5104 so long as the data FIFO 
5104 is not full. Further, the L bus master sequencer 5101 
asserts a master transfer request signal {LbMReq or LgMReq) 
and requests the external bus controller {the 10 bus 

15 controller 5002 or G bus controller 5003) for data transfer 
so long as the data FIFO 5104 is not empty. The external 
bus controller (the 10 bus controller 5002 or G bus controller 
5003) transfers the data of the data FIFO 5104 and asserts 
a master transfer notification signal (LbMAck or LgMAck) at 

20 the end of the transfer. The L bus master sequencer 5101, 



- 98 - 



therefore, is capable of recognizing the end of the transfer 
to the external bus. 

In a transfer from the external bus to the copy engine, 
the L bus master sequencer 5101 asserts the master transfer 
5 request signal (LbMReq or LgMReq) , requests the external bus 
controller (the 10 bus controller or G bus controller) for 
data transfer and writes the data to a data FIFO so long as 
the data FIFO is not full . Further, the L bus master sequencer 
5101 asserts the IFMDTACK signal, requests the copy engine 
10 for data transfer and writes the obtained data to the data 
FIFO so long as the data FIFO is not empty. 

(IO bus controller) 

Fig. 52 is a block diagram of the 10 bus controller 5002 . 
The 10 bus controller 5002 is an interface for 
15 interfacing the L bus and 10 bus. 

The 10 bus master sequencer 5201 controls operation in 
case of the 10 bus master and the 10 bus slave sequencer 5202 
controls operation in the case of the 10 bus slave. 
[Operation when copy engine is master] 
20 Data transfer starts in response to assertion of the 

LbMReq signal from the bus selector unit 5001. The direction 
of the transfer is decided by an LbMRdJNfotWr signal from the 
bus selector unit 5001 asserted at the same time as the LbMReq 
signal. The size of the transfer is decided by an 
25 LbBstCnt[l:0] signal from the bus selector unit 5001 asserted 
at the same time as the LbMReq signal. Further, the transfer 
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address is decided by an LbMAddr [31:2] signal from the bus 
selector unit 5001 asserted at the same time as the LbMReq 
signal. 

If the data FIFO for reading is full (i.e., if bRFif oFull 
5 has been asserted) , the transfer from the 10 bus {namely when 
the LbMRdNotWr signal is "0") waits until the FIFO is no 
longer full. The 10 bus sequencer starts the transfer on 
the 10 bus decided and the obtained data is written to the 
data FIFO of the bus selector unit 5001. 

10 If the data FIFO for writing is empty (i.e., if 

bWFifoEmpt has been asserted) , the transfer to the 10 bus 
(namely when the LbMRdNotWr signal is "1") waits until the 
FIFO is no longer empty. The 10 bus sequencer starts the 
transfer on the 10 bus decided and the obtained data is sent 

15 out on the 10 bus from data FIFO of the bus selector unit 
5001. 

(G bus controller) 

Fig. 53 is a block diagram of the G bus controller 5003 . 
The G bus controller 5003 is an interface for 
20 interfacing the L bus and G bus. 

The G bus master sequencer 5301 controls operation in 
case of the G bus master and the G bus slave sequencer 5302 
controls operation in the case of the G bus slave. 
[Operation when copy engine is master] 
25 Data transfer starts in response to assertion of the 

LbMReq signal from the bus selector unit 5001. The direction 
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of the transfer is decided by the LbMRdNotWr signal from the 
bus selector unit 5001 asserted at the same time as the LbMReq 
signal. The size of the transfer is decided by an 
LbBstCnt [1:0] signal from the bus selector unit 5001 asserted 
5 at the same time as the LbMReq signal. Further, the transfer 
address is decided by the LbMAddr [31 :2] signal from the bus 
selector unit 5001 asserted at the same time as the LbMReq 
signal . 

If the data FIFO for reading is full (i.e. , if gRFifoFull 
10 has been asserted) , the transfer from the G bus (namely when 
the LgMRdNotWr signal is "0") waits until the FIFO is no 
longer full. The G bus sequencer starts the transfer on the 
G bus decided and the obtained data is written to the data 
FIFO of the bus selector unit 5001. 
!5 If the data FIFO for writing is empty (i.e., if 

bWFifoEmpt has been asserted) , the transfer to the G bus 
(namely when the LgMRdNotWr signal is "1") waits until the 
FIFO is no longer empty. The G bus sequencer starts the 
transfer on the G bus decided and the obtained data is sent 
20 out on the G bus from data FIFO of the bus selector unit 5001. 
2.10. Power management unit (PMU) 

Fig. 54 is a block diagram of the power management unit 

409. 

The DoEngine is a large-size ASIC having an internal 
25 CPU. When all of the internal logic operates at the same 
time, therefore, a large amount of heat is produced and there 
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is the danger that the chip itself will be destroyed. To 
prevent this, the DoEngine manages power, i.e., performs 
power management, block by block, i.e., and monitors the 
amount of power consumption of the overall chip. 
5 Power management is carried out individually for each 

block. Information relating to the amount of power consumed 
by each block is collected in the power management unit (EMU) 
409 as power management levels. The PMU 409 totals the amount 
of power consumed by the blocks and monitors the amount of 
10 power consumption of each block of the DoEngine collectively 
so that the total value of power consumption will not exceed 
a boundary power consumption. 
<Operation> 

The operation of the power management blocks will now 
15 be described. 

•Each block has four power management levels. 
•The PMU holds the value of power consumption at each 
level in a configuration register. The level configuration 
and power consumption value are held in a PM configuration 
20 register 5401. 

•The PMU accepts the power management level from each 
block as a 2 -bit status signal (described below) and 
ascertains the power consumption of each block by making a 
comparison with the value set in the register 5401. 
25 * The sums the power consumption of each block using 

an adder 5403 and calculates the overall amount of power 
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consumption of the DoEngine in real-time. 

♦The calculated amount of power consumption is 
compared, by way of a comparator 5404, with a limit value 
(PM limit) on power consumption set in the register 5401. 
5 If the limit value is exceeded, an interrupt generator 5405 
issues an interrupt signal. 

The limit value can be set to two stages. The first 
stage sets a value having a small amount of leeway with 
respect to the true boundary. When this value is exceeded, 

10 an ordinary interrupt signal is issued. The software 

receives this signal and does not start a transfer that will 
activate a block anew. However, a new block can be activated 
under the management of the software within a range in which 
the second-stage limit value is not attained. The 

15 second-stage limit value sets a value at which there is the 
danger of device destruction. In the event that this value 
is exceeded, an NMI (an interrupt for which an interrupt mask 
cannot be set) is issued to shut down the system for the sake 
of safety. 

20 -The interrupt signal is canceled by reading a status 

register 5402 of the PMU. A time counter is activated at 
the moment the status register 5402 is read. If the amount 
of power consumption does not return by the time the timer 
runs out of time, the interrupt signal is issued again. The 

25 timer value is set in the register 5401 of the PMU. 
<Power management of each block> 
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Power management control of each block may be set up 
freely block by block. Examples of arrangements will be 
illustrated. 

(Arrangement 1) 

5 In this example power management is performed by turning 

a clock to internal logic on and off, and the level of power 
consumption has only two stages. This level is sent to the 
power management unit 409 as a status signal. Fig. 55 is 
a block diagram of a bus agent. 
10 -A bus agent 5501 includes internal logic 5502 for each 

unit, a decoder 5503 for decoding addresses, a clock 
controller 5504 and a clock gate 5505. 

-The decoder 5503 and clock controller 5504, which 
operate at all times, execute power management control, 
15 namely monitoring of bus activity and gating of clocks to 
internal logic. 

<Clock control> 

•The bus agent detects bus activity and turns the clock 
on and off automatically. 
20 'The bus agent has three states, namely sleep, wake-up 

and wait. 

•The sleep state is a state in which the bus agent 
exhibits no activity and the clock gate clock has been 
stopped. 

25 *The decoder 5503 and clock controller 5504 are 

operating even in the sleep state; they monitor the bus and 
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wait for a request. 

•When the decoder 5503 detects its own address, the 
clock gate 5505 is opened, the clock of the internal logic 
is activated and a bus request is complied with. The state 
5 shifts to the wake-up state. In addition, the power 
management control unit 409 is notifies of this state. 

•When data transfer ends, a transition is made to the 
wait state and the next request is awaited. The clock remains 
active. If there is a request, the wake-up state is restored 

10 and a transfer is carried out. Counting is performed by the 
timer while a request is being awaited. If the timer runs 
out of time without a request being issued, a transition is 
made to the sleep state and the clock is stopped. The power 
management unit 409 is notified of this state as well. 

15 Thus, management is performed in such a manner that 

power consumption will not exceed a predetermined value. 
[Other example of arrangement of DoEngine] 
The cache operating procedure shown in Figs. 9 and 10 
may be replaced by that shown in Figs. 56 and 57. 

20 If data transfer is started from the MC bus in Fig. 56, 

it is judged whether the transfer is performed with cache 
ON or with cache OFF depending upon mTType[60:0] indicated 
on the MC bus at the start of the transfer. When the transfer 
is burst transfer, the judgment is made based upon whether 

25 the amount of the burst transfer is greater than or less than 
the amount of data on one line of the cache. It should be 



- 105 - 



noted that one line of the cache is 256 bits, which is 
equivalent to four bursts. 

In Fig. 56, the memory controller checks mTType[3:0] 
at the start of transfer. If the burst length indicated by 
5 mTType is 1/2/4, operation is with cache ON. In case of 
6/8/16/2 X 16/3 X 16/4 X 16, operation is with cache OFF. 
Operation after the cache is turned on or off is similar to 
that described in connection with Figs. 9 and 10. 

Cache ON /OFF can also be changed over by a device as 

10 illustrated in Figs. 58 and 59. In Fig. 58, the memory 
controller identifies the transfer requesting device by 
checking mTType [6: 4] at the start of transfer, refers to the 
previously set value in the configuration register in order 
to determine whether the transfer request of this device is 

15 actuated with cache ON or cache OFF, and decides whether 
operation is with cache ON or cache OFF. Operation after 
the cache is turned on or off is similar to that described 
in connection with Figs. 9 and 10. The setting of the 
configuration register may be decided by hardware (in which 

20 case any change is not possible) or rewritably by software. 
[Effects of the invention] 

As described above, the present invention is such that 
in a case where DMA is performed successively, the software 
need not intervene whenever a bus master is changed. 
25 Conditions for starting and conditions for ending DMA are 
first set collectively in a bus arbiter beforehand and DMA 
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setting is made in the bus master as well, whereby the bus 
master is capable of subsequently executing a series of 
processing operations while controlling the sequence. As 
a result, software intervention for every processing 
5 operation is no longer necessary. Further, writing data back 
to memory each and every time is not required. This means 
that the number of times data uses a bus is reduced, thereby 
raising overall processing speed. 

Further, the bus connected in response to a request is 

10 changed over by a crossbar switch so that data can be 

transferred by selecting the optimum bus. Furthermore, if 
the bus arrangement is provided with flexibility and the 
master and slave do not overlap, a plurality of buses can 
be connected in parallel to improve the efficiency with which 

15 buses are used. 

In regard to bus masters connected to respective ones 
of a plurality of buses, the bus masters perform control in 
such a manner that a memory is accessed in the order in which 
bus use privilege is obtained. As a result, sequence of 

20 processing attendant upon the passage of time can be 
maintained in proper fashion. 

In the burst mode having a high transfer speed, a cache 
is not used. A cache is employed in the single mode. This 
prevents a situation in which a large quantity of cached data 

25 is wasted, thereby raising cache utilization efficiency as 
well as the speed at which data is transferred to memory. 
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The bus used by each bus master is decided and selected 
dynamically depending upon bus use status, priority of bus 
request, bus performance and whether data to be transferred 
is suited to the bus. This makes it possible to improve bus 
5 efficiency. 

Further, the operating state of each block of the 
circuitry is monitored to suppress power consumption. 
Furthermore, notification is given of preliminary warnings 
and hazardous conditions by separate interrupt signals. As 
10 a result, the generation of a large amount of heat is 

suppressed and destruction of the apparatus due to heat can 
be prevented. 

As many apparently widely different embodiments of the 
present invention can be made without departing from the 
15 spirit and scope thereof, it is to be understood that the 
invention is not limited to the specific embodiments thereof 
except as defined in the appended claims. 
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